Varied interface method visibility (was Final defenders)

[Daniel Latrémolière]

> 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.
I think this choice was due to persisting confusion in nature on class 
vs. interface. Since some years on lambda and some debates on traits, I 
have see two points of view:

The good one for me:
- class is defined by having a state and then allowing only single 
heritance (of state and behaviour).
- interface is defined by having no state and then allowing multiple 
heritance (of behaviour).

The bad one for me:
- interface is a contract.
- class is an implementation.

The second is bad for me, because contract is defined by publishing API: 
the "public" keyword (or smaller scope with package or protected). You 
have a contract only because various people use same method (same 
signature more precisely). A public class is also a contract: you can 
not change signature of its public methods without breaking contract 
(then contract role is not only for interfaces but for classes also).

A trait is without state but is an implementation, then we have seen 
many debates between the two points of view. If we keep only the first 
point of view, we will see trait as a natural extension of interface 
with various visibility and abstract/implemented methods (better 
flexibility).

A contract interface will only become a design pattern using interface, 
like many others design patterns. By example, you can even currently 
define tuple as a design pattern in Java with a class containing public 
final fields (even if passing it by value in JVM will need some 
additions, like good tagging [1]).

Daniel.

[1]: https://blogs.oracle.com/jrose/entry/value_types_in_the_vm