Updated State of the Lambda

[Martijn Verburg]

Hi all,

I can understand that some syntax could be confusing, or makes
understanding the semantics a little more difficult to understand, but
don't we until late 2013 to nail the syntax down? I personally fall
into this trap of thinking about syntax first, but having done some
DSL work and hanging around with too many language geeks ;-) in the
past year it's made me think the other way around.

I think it would be more beneficial if we all dive in a little deeper
and investigate/tackle the semantic issues first. I think that they
need more upfront thinking and longer time to resolve any issues than
getting the compiler to recognize a syntax change.

It probably will help to have a wiki/doc on why some syntax decisions
have already been made (or ruled out) so we can point people to an FAQ
of sorts.  I'll have a chat with Richard to get this started.

@Everyone - we're the best place for this?  A wiki page on openjdk.java.net?

Cheers,
Martijn

On 12 December 2011 13:01, Stephen Colebourne <scolebourne at joda.org> wrote:
> On 12 December 2011 11: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).
>
> Yes, there are complications, but I don't think "default none" is the
> right solution.
>
> The key problem (which I think is more in the JDK than in other code
> I've seen) is documentation, but that documentation problem also
> applies to classes. A better solution would be to provide a way to add
> documentation to a sub interface/class without creating a new
> signature in the bytecode.
>
> Another solution would be to use the abstract keyword, perhaps at the
> end in place of "default none".
>
> I'm simply saying that "default" in general and "default none" in
> particular don't have any appeal at this point.
>
> Stephen
>