Default method survey results

[Maurizio Cimadamore]

On 16/08/12 14:15, Rémi Forax wrote:
> On 08/16/2012 11:47 AM, Maurizio Cimadamore wrote:
>> On 16/08/12 10:13, Alex Blewitt wrote:
>>> The point of confusion - where the method is coming from - is at use
>>> site of the interface, not declaration site. What keywords you use at
>>> the declaration site (probably written by someone else) will make
>>> absolutely no difference to the person who implements that interface,
>>> keyword or not.
>> How do you get to know the set of methods that have to be implemented
>> when you implement an interface? Probably you go and look at the Javadoc
>> for that interface. Then you see a list of methods, some of which have
>> the D-word; you know that, at the very least (i.e. not to get
>> compile-time errors) you have to implement all the remaining ones (w/o
>> the D-word).
>>
>> But I think we are a bit down into a syntactic rat-hole here - the
>> original question was - why not allowing a third option in the survey,
>> one that mandates no keywords at all to denote an 'interface method with
>> body'. The motivations behind the choice were several, including:
>>
>> *) 'default' will make the interface code easier to parse
>>
>> *) a keyword will provide an handy 1-1 mapping between source code and
>> Javadoc
> but there will be no 1 to 1 mapping with the JVM bytecode,
> there is no default modifier in the generated class file as far as I know.
Mapping with the JVM bytecode doesn't affect readability, or 
understanding of a feature, while a clear mapping vs. javadoc does.
>
> And for javadoc, it's often better to present information in a different
> way than the one given by the source,
> by example, you have all direct subtypes of a type even if you don't
> declare them in the source.
>
>> *) 'default' is the dual of 'abstract' - it must be specified in
>> interfaces the same way as 'abstract' must be specified in classes
> see Peter Levart answer, default is not the dual of abstract.
> The dual of abstract method is concrete method, which up to now, doesn't
> require any keyword.
You are reading my words too strictly. What I'm saying is that there 
already is a place where you have to specify a keyword where the 
compiler could obviously infer one for you. And yet, I haven't seen that 
many discussions as to why compiler requires you to write:

class Foo {
_abstract_ foo();
}

isn't that obvious? There's no body!!! Should we change the 
compiler/language? I don't think so - for the same reasons as I think we 
should keep 'default'.
>
>> *) the presence of a keyword will help extending the syntax even more by
>> adding new default forms
> the EG has rule out any extra syntax other than the classical syntax to
> declare a method body.
I see, what about JDK 19?
Sorry should be JDK 20, JDK 19 is for effectively default ;-)
>
>> *) 'default' summarises the semantics pretty well
> We already have 'abstract' that mean should be implemented,
> why do you want a keyword with the meaning, non-abstract but only in the
> case where the method is defined in an interface.
I think default != concrete - at least under some interpretations of it. 
In the example I gave, you have a concrete method that does not override 
an abstract method in the superclass, because superclass methods always 
win, even if abstract. This is what, in my mind at least, makes a 
default method a different beast.

Maurizio
>
> Moreover, non abstract method in interface change the way the VM
> populates the class vtable by using code of method declared in interfaces,
> so the semantics you're talking about, the semantics that change, is the
> semantics of 'implements',
> not the semantics of the non-abstract method by itself. (cf Stephen
> Colebourne reply)
>
>> What are the motivations behind leaving the 'default' keyword out? Note:
>> it must be more than just avoiding to type 'd' 'e' 'f' 'a' 'u' 'l' 't' -
>> which, as you say, probably somebody else would have typed in for you ;-)
>>
>> Maurizio
> Rémi
>
>
>