Default method survey results

C.J. Kent cjkent at
Sat Aug 18 03:27:09 PDT 2012

On 18 Aug 2012, at 09:15, "maurizio cimadamore" <maurizio.cimadamore at> wrote:

> On 17-Aug-12 3:19 PM, Paul Benedict wrote:
>> 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.
> If you are coming from 'a default method is a concrete method', then I 
> agree, the argument is pretty strong.
> But it would not reflect the behavior very well; as pointed out by Remi, 
> a default method is essentially an abstract method with a 'suggestion' 
> for the VM - if no implementation can be found for a given method, 
> here's one for you. The class-hierarchy establishes as to whether the 
> method becomes concrete or remains abstract.
> Since this semantics is subtly different from the one of standard 
> concrete methods in classes, why would you want to use the same syntax 
> for both concepts, or claim that it would not cause confusion to do so?
> Maurizio

I don't see why it would cause confusion, the rule is simple: a method definition with a body has different semantics depending on whether it's in a class or an interface.

The same is true of method definitions without bodies. Their semantics are subtly different depending on whether they're in a class or interface. And everyone seems to manage without getting too confused.


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

More information about the lambda-dev mailing list