Updated State of the Lambda

[Howard Lovatt]

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


-- 
  -- Howard.