Default method survey results

David Holmes david.holmes at
Fri Aug 17 03:17:15 PDT 2012

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.

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


> 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