Updated State of the Lambda

[Howard Lovatt]

There are plenty of annotations like @Reabstract in common use, e.g. @Test
in JUnit (it completely changes the meaning of a method - whether it is
part of the test suite or not). I don't see this as any different, it is
just qualifying an otherwise ambiguous meaning.

As I think others have said people will get used to default and default
none, so this isn't a big point, just a suggestion.

The main thing I like in this version of the state of the lambda is that
defender methods can have bodies and I am very glad that solid progress is
underway.

On 13 December 2011 12:32, Neal Gafter <neal at gafter.com> wrote:

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


-- 
  -- Howard.