Project Lambda: Java Language Specification draft

Osvaldo Pinali Doederlein opinali at gmail.com
Sat Jan 23 10:16:12 PST 2010


Em 22/01/2010 23:36, Neal Gafter escreveu:
> [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 would add that the typecast needed to invoke methods from the SAM type 
is really ugly. Addtional typecasts are not the direction the language 
should be evolving - this smells like a broken/bad typesystem. If my 
lambda is actually a TimerTask, and the compiler obviously knows that, 
why should I write a cast? Every explicit cast is a new, golden 
opportunity for ClassCastException (if I write the wrong type). It seems 
the typecast syntax is being abused to mean something completely 
different, i.e., to just get access to the SAM type's members, but not 
to tell the compile that 'this' is really a member of that type (no 
checkcast bytecode will be issued, I suppose). At the very least, I'd 
want a different syntax - perhaps reuse the [lambda-specific] bang 
operator, e.g.

   m( #() { this!cancel(); );

I didn't like this use of the bang too (agree with other posters - 
confusion with negation etc), nor did I like the handling of this inside 
closures; but if both features are approved, please reconsider at least 
the syntax for access-to-SAM-type-members...

A+
Osvaldo




More information about the lambda-dev mailing list