Project Lambda: Java Language Specification draft

[Stephen Colebourne]

Thanks for the first draft. I agree with much of Neal's detailed analysis.
more inline:

2010/1/23 Neal Gafter <neal at gafter.com>:
>> [15.8.3 this]
>> The keyword this may be used only in the body of an instance method,
>> instance initializer or constructor, or in the initializer of an
>> instance variable of a class, *or in a lambda expression*.
>>
>> The type of this in a lambda expression is the function type of the
>> lambda expression.
>>
>> /*
>> Treatment of 'this' inside a lambda expression is essentially the same
>> as 'this' inside the body of an anonymous inner class.
>> */
>
> That's the worst possible treatment of "this".  It has all the
> disadvantages of the inner class approach (not being transparent) with
> none of the advantages (you can't use any inherited members of the
> type to which the lambda expression is converted).  This is the first
> time I've heard anyone advocate such treatment for "this".

I agree, this usage of "this" is confusing and unintuitive. I strongly
support "this" being a reference to the enclosing object.

>> Any local variable, formal method parameter, or exception handler
>> parameter used but not declared in a lambda expression must be
>> effectively-final.
>>
>> A local variable, formal method parameter, or exception handler
>> parameter is effectively-final if it is never the target of an
>> initialization or assignment expression except where definitely
>> unassigned.
>
> In other words, can't capture much more than an anonymous inner class
> could.  Disappointing.

I hope that this can be extended to support other ways of interacting
with local variables.

>> Therefore, it is convenient for the body of a lambda expression to
>> have access to members of the SAM type. To achieve this, I am thinking
>> that 'this' in the body of the lambda expression may be cast to the
>> SAM type:

Bad idea. And not necessary.

Stephen