Preparing for the 0.2 draft

[Fredrik Öhrström]

Joshua Bloch wrote:
>  The "foo.()" invocation syntax looks like a winner,
>
>
> Agreed.
>
>   
I do not agree, it looks like a syntax error. Use two more characters 
"do" or use "invoke".

> True, but I haven't heard *any *arguments in favor of the "transparent this"
> that are in any way applicable to Java. Maybe I'm being dense, but I believe
> it's cargo cult language design.  In Java, I believe it would be a
> gratuitous inconsistency, pure and simple.  And I believe it would bite us
> sooner rather than later.  If I'm wrong, I'd love to see some compelling,
> practical examples where having this refer to the enclosing instance is
> useful (in Java).
>   
I think you only argue for "this" to refer to the lambda itself, is 
because you think you know how the lambdas are going to be implemented.

Just because every piece of code in Java you have written so far, has 
been a method inside an object, does not mean that every piece of code 
in Java in the future will be a method inside an object. In the future 
you will (hopefully) be able to write lambdas and these are not methods 
inside an object. These are functions potentially executing inside a 
lexical environment.

Rémi makes a very important point, when he points out that a method 
inside an object is not the same thing as a function. "this" is used to 
refer to an object from inside one of its methods, and sure, the 
lambda/closure looks like an object from the outside, but it is >not< an 
object from the inside. Notwithstanding how it might be implemented.

Smalltalk has had lambdas (blocks) for ever, and has never had any way 
to refer to the block itself from within itself, other than for example 
assigning the block to a variable that the block closes lexically over.

I agree fully with John Rose on that the design of the current lambdas 
should not prevent a future upgrade into a more complete control 
abstraction.  Making "this" refer to the lambda itself not only breaks 
transparency preventing future upgrades of the lambdas, it also limits 
how we can implement lambdas. It is also completely unnecessary as long 
as you make sure that you can assign a lambda to a local variable and 
still have the lambda close over the variable, this should be part of 
the specification.

//Fredrik