Updated State of the Lambda

[Neal Gafter]

I think it would be a bad idea to have annotations affect/change the
meaning of code.

On Mon, Dec 12, 2011 at 5:17 PM, Howard Lovatt <howard.lovatt at gmail.com>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
> >
> >
>
>
> --
>  -- Howard.
>
>