Default method survey results

[Jack Moxley]

If only we could Remove abstract or at least make it optional much like public on interface method declarations. Then perhaps we might have a language a little less like a bunch of plasters piled up on top of each other, each separate angle decided by committee, with little thought for the poor sod who has to use it.  Case in point being, the remove on iterator, you can only use it if you know the implementation of your iterator, so in most cases you can't and people don't. However I saw 10 emails discussing this poorly thought out API, as though it's the perfect example on how to use the changes to the language.

Keep it simple, keep it easy, keep it unambiguous! 

Also throwing an exception notifying at runtime that a method is not supported fails the strongly typed test and the sensible API test in my book.

Sent from my iPhone

On 18 Aug 2012, at 11:27, "C.J. Kent" <cjkent at hotmail.com> wrote:

> On 18 Aug 2012, at 09:15, "maurizio cimadamore" <maurizio.cimadamore at oracle.com> 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.
> 
> Chris
> 
>>> 
>>> 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
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>> 
>> 
>> 
>