Varied interface method visibility (was Final defenders)
talden at gmail.com
Wed Aug 8 03:59:50 PDT 2012
On Wed, Aug 8, 2012 at 9:49 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> On 8 August 2012 08:28, "Zdeněk Troníček" <tronicek at fit.cvut.cz> wrote:
>> Could you give any examples of those "huge dividends"? Could you show when
>> protected methods in interfaces are useful?
>> I have already asked for examples of protected interface methods in this
>> conference and did not get any.
> JSR-310 has an example, where we have to use a "do" naming prefix
> together with lots of Javadoc for methods that should be protected on
> an interface:
> If you look further up that same class you'll see the compare method
> is marked as one that should be a default method.
> This is an interface because it is implemented by enums. So, proper
> traits functionality would solve much of another requested feature -
> "abstract enums".
> By not adding protected/private/package methods from the start of this
> feature, we are going to end up with design mess-ups like the "do"
> naming prefix in JSR-310, simply to get around an inadequate feature.
> A second case is where I want an interface that is limited in scope to
> a package. While the interface can be declared package-scoped, all the
> methods are still public in scope. This causes the implementations to
> have to declare their methods public, which nullifies the usefulness
> of the design.
The decision to make all interface members public was indeed an
unfortunate decision. That any use of interface in internal design
exposes implementation private details is a big one.
It's a tough one to fix without adding some obscure or compatibility
breaking nuances to the language. A compatibility break of that
magnitude and potential subtlety would seen unconscionable so a
solution has to exist that doesn't break existing code.
Could reintroducing the 'package' keyword as an access-specifier be
viable. It's absence of a specifier in an interface would imply
public-access and the absence of a specifier in a class implies
package-access. Which specifiers make sense in an interface is unclear
- especially if, to minimise the knowledge burden on developers, we
have to ensure that access-specifiers mean the same thing in both
class and interface if they're present.
In the absence of default methods I'd have speculated that the
specifier of a member in an interface has to be at least as visible as
the interface itself (so the interface can actually be implemented in
all visible contexts) - with default methods that's not so certain.
Has there been any clear communication as to whether this is even a
possible in-scope discussion? If not, should it be held elsewhere.
More information about the lambda-dev