Default method survey results

[Maurizio Cimadamore]

On 17/08/12 11:17, David Holmes wrote:
> On 17/08/2012 7:12 PM, Maurizio Cimadamore wrote:
>> 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' ;-)
>
> Well you said "there already is a place where you have to specify a 
> keyword where the compiler could obviously infer one for you" - which 
> indicates the keyword is unnecessary. That's the wrongness to me, and 
> you now want two of them.
The same reasoning could be applied to variable types then - since the 
compiler could infer them, it indicates they are useless. Sorry, but I 
don't buy the argument 'since the compiler can infer XYZ, we don't need 
XYZ'. To the extreme it will lead to cryptic code (at best).
>
>>> 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'.
>
> Sorry but I don't see how any of the above suggest in any way that any 
> keyword is needed. If anything it highlights to me that no single 
> keyword is going to be able to capture the semantics in a meaningful 
> way, so any keyword is likely to cause confusion more than clarity.
>
>>>
>>> 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.
>
> It is not a distinction I am grokking. A concrete method (in a class 
> or interface) provides an implementation that under certain 
> circumstances will be the method executed. You can't tell what those 
> circumstances are by looking at the method alone, so no keyword 
> attached to the method is going to provide any assistance.
>
> Cheers,
> David
>
>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>