Varied interface method visibility (was Final defenders)

[Talden]

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:
> https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/calendrical/DateTimeField.java#L131
>
> 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.

--
Aaron Scott-Boddendijk