> I am not a fan of protected. Other than indicating explicitly that subclasses are supposed to override this method, are there any other benefits?
I believe it is a good approach not to publish things that don't need to be public. It is a node implementation thing, it should not confuse users in the list of publicly accessible methods. Other than you not being a fan, are there any concrete reasons for it to be public? (the fan thing doesn't leave much room for discussion)
<rant>
Steve says: "Protected is a waste of time. There is only API in the world. API is something people see. Non-API is your implementation. Every time I have defined a method to be protected in the past, I have always later wanted it to be public. The advantage of protected is that it indicates that you should override it but we have @Override for that now."
</rant>
I believe it is a good approach not to publish things that don't need to be public. It is a node implementation thing, it should not confuse users in the list of publicly accessible methods. Other than you not being a fan, are there any concrete reasons for it to be public? (the fan thing doesn't leave much room for discussion)
<rant>
Steve says: "Protected is a waste of time. There is only API in the world. API is something people see. Non-API is your implementation. Every time I have defined a method to be protected in the past, I have always later wanted it to be public. The advantage of protected is that it indicates that you should override it but we have @Override for that now."
</rant>
- blocks
-
JDK-8100124 Create API for determining the layout direction of a component
-
- Closed
-
- relates to
-
JDK-8102424 Node Orientation - API issue: Is isAutomaticallyMirrored() named properly?
-
- Closed
-
-
JDK-8099289 Support component orientation in common UI controls
-
- Closed
-
-
JDK-8100148 Add RTL support to Text node
-
- Closed
-