Default method survey results

[Paul Benedict]

Maurizio,

I think those opining for scuttling the "default" keyword have a
strong argument. Concrete methods don't need any special keywording
today with classes; likewise it shouldn't also be necessary in
interfaces. A coder doesn't need to say "Hey, I am providing an
implementation" two times: once with "default" and then again with
curly braces. The special treatment is just not required ... or even
helpful. As someone just said, default methods are new today but they
won't be in 5 years. Adding the keyword draws attention to the method
for the wrong reason: it is just an exercise on emphasizing the
newness of this functionality.

Paul

On Fri, Aug 17, 2012 at 6:11 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>
>