Default method survey results

[David Holmes]

On 16/08/2012 11:33 PM, Maurizio Cimadamore wrote:
> 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'.

This is a hollow argument. In 1995 the then language designers made a 
decision about how to express abstract classes and methods and the world 
was gradually introduced to that over the next few years. Some people 
undoubtedly thought the syntax was too verbose, but on the other hand 
defining explicitly abstract classes and methods was something 
relatively new to OO programmers. There was no community then to discuss 
the issues.

Jump forward to 2012 and we have a vibrant community and when people are 
presented with new language proposals they get to evaluate them and 
express their views. One such view held by a number (myself included) is 
that the default keyword is simply superfluous. Arguing that default 
belongs because we already another superfluous keyword is just unsound 
reasoning. Two wrongs don't make a right.

None of the other "arguments" carry any weight with me either. The whole 
notion of default-ness is context dependent. You can't look at an 
interface declaration and know whether a method implementation will be 
an actual default for anything - you have to see the entire type 
hierarchy for that.

> 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.

This part almost slipped past me! Your example:

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

class B {
     abstract void m();
}

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

On the surface this seems surprising and wrong to me. I thought a 
superclass _implementation_ of a method always wins and an abstract 
method has no implementation. That said I can see we may be getting into 
a corner where the resolution story is difficult to express in a simple 
way yet still give all the desired results (in this case I view the 
desired result as the interface default taking precedence over the 
superclass abstract method). Re-abstraction at the class or interface 
level certainly complicates things (but is necessary).

But actually won't the above be a compilation error because class C 
would need to be declared abstract? That would at least alter the 
developer that this may not be working the way they might have expected 
and they can explicitly delegate to A.m().

Thanks,
David


> 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
>>
>>
>>
>
>