Default method survey results

[Maurizio Cimadamore]

On 16/08/12 21:42, David Holmes wrote:
> 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.
I think you misread what I've said. In my view it's not 'two wrongs', as 
I don't think 'abstract' should be removed. So, for me it's more like 
'two rights 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).
I think the above summarises pretty well why we need a different 
keyword, and why the meaning can sometimes be a bit more subtle than 
just 'concrete'.
>
> 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().
Yeah - that would be a compile-time error because C is not abstract - at 
which point one could ask - why is this not working? I have a 'concrete' 
method in A, why the compiler is not picking that up? As you said, the 
notion of 'default-ness' is context dependent (more precisely, it's the 
notion 'defaultness-becomes-concreteness' which is context-dependent), 
while the notion of 'concrete-ness' is not. That feels like an important 
distinction.

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