Updated State of the Lambda

[Brian Goetz]

No.  We do not use annotations to express program semantics.  Your 
statement that this is comparable to @Override is incorrect; @Override 
represents a property that can be checked at compile time and discarded. 
  But inheritance is calculated at runtime, so things like "default 
none" need to go into the bytecode.

On 12/12/2011 8:17 PM, Howard Lovatt wrote:
> An alternative to the current suggestion of m() default { ... } is:
>
>    m() { ... }
>
> for m() default none:
>
>    @Reabstract m();
>
> for m();:
>
>    @JavadocOnly m();
>
> and
>
>    m();
>
> issues a warning but behavies like @JavadocOnly. This is in line with
> current Java practice, in particular abstract classes and @Override, and is
> compatible with old code.
>
> On 12 December 2011 22:46, Maurizio Cimadamore<
> maurizio.cimadamore at oracle.com>  wrote:
>
>> On 12/12/11 11:21, Stephen Colebourne wrote:
>>> At this point, I find the "default" keyword in default method
>>> interfaces to be noise, and adding no value. Method bodies in
>>> interfaces is not a complex concept, nor an unreadable one. The
>>> default keyword makes it more complex and noisy, not less. Removing
>>> "default" would also mean removing "default none", which again makes
>>> perfect sense. Redclaring a method in a subinterface for documentation
>>> purposes is rare, and for classes requires a call to super, so the
>>> same should apply for interfaces.
>>>
>> Note that the presence of 'default none' is not accidental, nor driven
>> by a syntax decision. An extension method whose body is 'default none'
>> is used to explicitly get rid of any defender that might have been
>> inherited up to that point. It is the equivalent of re-abstraction of
>> concrete methods, but applied to extension methods. We feel like we need
>> an explicit re-abstraction mechanism, as it is quite common in Java code
>> to repeat an interface method declaration is a sub-interface just for
>> documentation purposes. If the redeclaration was interpreted by the
>> compiler as a re-abstraction we would be introducing subtle semantics
>> change associated with such re-declaration of interface methods and the
>> only way out for the developer would have been to re-specify the default
>> implementation for the extension method (which would be the most common
>> use case, as opposed to re-abstraction, which is quite rare).
>>
>> Maurizio
>>
>>
>
>