Updated State of the Lambda

[Richard Warburton]

>>and you need 'default none' to re-abstract a method of an interface,
>>i.e. to say I don't want to inherits from the default implementation.
>>
>>interface I {
>>  void m() default { ... }
>>}
>>interface J extends I {
>>  void m() default none;
>>}
>>class A implements J {
>>  // don't compile, you need to provide a code for m()
>>}
>>
>>Because methods defined in an interface are always abstract,
>>you can't use abstract instead of default none.
>>
> Have you considered 'default null'?  It will save a keyword - even if it is only a local one - and it conveys the appropriate meaning (compare this to setting a variable to null to indicate that the referred to object is no longer needed).

Re-abstracting a method isn't really the same as assigning to a null
reference.  Also, I'm not entirely convinced that proposing
alternative keyword choices - whilst an exercise we can all
participate in - is necessarily the most productive line of
discussion.

On a semantic issue, I'm a bit confused as to what happens in diamond
inheritance situations? Specifically I'm thinking of a case similar to
the following:

interface A { void m() }
interface B1 extends A { void m() default { System.out.println("one"); } ... }
interface B2 extends A { void m() default { System.out.println("two"); } ... }
class C extends B1, B2 {}

I apologise if I'm inadvertently re-opening discussion, but looking
through the archives I can see some discussion in the past over
whether this should simply be a compiler error due to ambiguity or
whether there should be disambiguation of this case in the method
resolution algorithm. This discussion was over a year old now, and the
examples offered didn't seem to necessarily match the same defender
method approach as today (this may be my misunderstanding of course).

regards,

  Richard