Preparing for the 0.2 draft

[Peter Levart]

On Friday 29 January 2010 09:56:46 Alex Buckley wrote:
> Many thanks for everyone's comments on the 0.1 draft. The "foo.()"
> invocation syntax looks like a winner,

There are pros and cons of this syntax. Pros include:
- visual resemblance to a method invocation in case function type value is held in a variable 
(which is close to a desire to reuse same syntax). 
- dot '.' is barely visible, so it doesn't produce additional syntactic noise.
- a dot in the syntax suggests that "we are selecting a member from a function type - a method?" 
but that method is anonymous so it's name is <empty>.

Cons:
- since every function type is a sub-type of Object, it has other public members: .hashCode(), 
.equals(), .wait(), .notify(), .getClass(). Invocation of the function is the only one that has 
no "name".
- invoking a value of function type that is not stored in a variable produces hard to "spot" 
constructs:

aRef.methodReturningLambdaReturningLambda(param1, param2).(param3).(param4, param5, param6);

Therefore my suggestion is the following:

Allow '#' to be used in the place of a method name:

lambdaRef.#(param1, param2);

This could be made consistent with reflection which would also report a Method with name "#" 
although the byte-code method name could be different.

Above chained example would then read:

aRef.methodReturningLambdaReturningLambda(param1, param2).#(param3).#(param4, param5, param6);


Regards, Peter

> 
> The discussion of transparent 'this' v. non-transparent 'this' comes
> down to the question of what a lambda in Java is for. (Zdenek Tronicek
> ably made this point earlier.) Part of the answer lies in understanding
> when to use an anonymous inner class and when to use a lambda
> expression. A step towards that understanding would be knowing how
> anonymous inner classes are used today.

Regardless of that, the best specification would be the one that allows using lambda expressions 
instead of anonymous SAM instance creation expressions by supporting all their features and at 
the same time allow things that are not possible with anonymous SAMs (transparency, non-local 
transfers). I believe, such specification is possible. It's just that such specification is not 
possible by blindly replicating features of anonymous SAM instance creation expressions.


Regards, Peter