Default method survey results

[maurizio cimadamore]

On 16-Aug-12 12:09 AM, Stephen Colebourne wrote:
> On 13 August 2012 15:24, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> *) a keyword (like default) at the beginning of the method declaration
>> will make it very clear and unambiguous that the following method
>> declaration is kinda special. Of course you could 'infer' the same
>> information by looking as to whether the method has a body or not, but
>> it's also a matter of clarity (think of cases where you have multiple
>> thrown types, annotations, etc.).
> In Java, a method is defined by placing a block of code after a method
> signature. There is no need to specify a loud "this is a method"
> keyword. Of course, the previous sentence refers to classes, but it is
> perfectly plain that once JDK8 is released, interfaces will act very
> much like classes without fields that can be multiply inherited. The
> team have worked hard to ensure that the inheritance is natural, yet
> fight against the last step to make it be natural! Stop trying to make
> it special simply because it is special to the compiler/JVM writer.
As I said previously - there's __nothing__ special about it for 
compilers, VM writers. Unless you think that, after adding unbound 
lookahead to support fluent lambda/method reference syntax (i.e. think 
of '(List<String>::foo)') , we suddenly have become so lazy that we 
don't want to add those two parser lines in order to infer the 
'default-ness' of an interface method ;-)

>
>> *) Proposals for alternate ways of specifying default method
>> implementations (i.e. other than specifying a method block) have been on
>> the table for quite some time; i.e. use a method reference to denote the
>> default implementation. Or some syntactic shorthand in case the only
>> thing you need to do is to disambiguate between two superinterface
>> members using a qualified super call. If such proposals will ever be
>> part of the language, it will be increasingly difficult for the human
>> reader to immediately grasp as to whether a method is a default method
>> or not, as the proposed 'has a block?' rule of thumb would no longer hold.
> The premise here is wrong. A method in JDK8, whether from an interface
> or a class, will inherit in essentially the same way. Clashing
> overrides are the main issue. Default-ness is not something a
> developer actively cares about here, and does not need to be specially
> marked.
>
> Now consider this code:
>
> interface Foo {
>    public String process(int a, String b) default Utils#processFoo
> }
> class Bar {
>    public String process(int a, String b) default Utils#processBar
> }
>
> The Foo version is being talked about for JDK8/9, yet the Bar version
> isn't. Why not? What is the difference here that justifies support for
> this feature in interfaces and not classes? None I'd suggest. But
> here, a keyword of some sort does make some sense - its a new feature
> not seen anywhere today. Methods that can be inherited are not a new
> feature, just one appearing in a new location (interfaces), thats why
> they don't need extra syntax.
I would say that the keyword 'default' in the class looks weird at best 
- why 'default' ? In an interface, default means that it's some kind of 
'last-chance' attempt at providing an implementation for a given method 
- hence the 'default'. There are already things in the model that make 
inheritance between classes and interface asymmetric (towards classes) - 
for example:

interface A {
    void m() default { ... }
}

class B {
    abstract void m();
}

class C extends B implements A { } //m is abstract in C

Which kinda makes the point about 'defaultness' even stronger: the 
default method is used _only if_ no other method exists in the 
superclass hierarchy. This concept simply does not scale to classes, so 
I don't buy the 'similarity' argument here. But, more importantly, for 
99% of developers an interface is - well, just an interface, an entity 
with a set of abstract methods, no implementations. The fact that 
implementations will start to appear in interface is potentially 
confusing to those developers, and we think that the use of a keyword 
(which, btw, reflect the semantics pretty well, as described above), 
will help developers to understand more quickly things like i.e. which 
methods they need to implement when implementing an interface. Also, 
let's not play down the Javadoc factor: once you name a method 'default 
method' you can use the D-word in javadoc to tag the method, and you 
have a nice 1-1 mapping between source code and documentation.

Maurizio
>
> Stephen
>