What is the meaning of this?

[Peter Levart]

On Tuesday 02 February 2010 23:35:01 Joshua Bloch wrote:
> Peter,
> 
> This is an interesting idea.  It certainly provides a way to access the
> function object from within its definition without polluting the surrounding
> scope, which is a good thing.  Of course the ability to do non-local returns
> scares the crap out of me.  Heck, I feel unclean when I do a labeled break
> in the language as it currently exists.
> 
>           Josh
> 
> P.S.  Your idea still leaves unanswered the question of what "this" *should
> *represent in the body of a lambda.

I'm a proponent of the following:

- unqualified (this, equals(), hashCode(), wait(), notify(),  notifyAll(), toString()) should be evaluated in the lambda's enclosing scope
- any unqualified fields or methods should be evaluated in the lambda's enclosing scope even if lambda is converted to a SAM subclass with plenty of members.
- the only way to obtain a reference to a function or SAM object is via a variable:
    final Runnable code = #() { ...; code.run(); ... }   // or maybe (but not prefferably)
    #code() { ...; code.(); ... }

I look at all that from the syntax perspective. I assert that when a die-hard-one-of-9-milion Java programmer sees an unqualified variable name or method invocation, she searches it's definition from the first enclosing class outwards (taking into account local variables that might shadow other vars).
The syntax of a lambda expression does not look like a class declaration - it contains no CamelCasedName in the header and no method declaration inside like all top/nested/anonymous classes - in frequent cases it boils down to 3 characters: '#()' - it looks more like a simple block of code with minimum header that represents formal parameters.

So when Alex says: "with nine million Java developers, designing something that looks familiar is a feature, not a bug.", he should ask himself what does the feature he is designing look familiar to.

Regards, Peter

> 
> On Sun, Jan 31, 2010 at 1:39 AM, Peter Levart <peter.levart at gmail.com>wrote:
> >
> > LambdaExpression:
> >    '#' Identifier_opt '(' FormalParameters_opt ')' Block
> >    '#' Identifier_opt '(' FormalParameters_opt ')' '(' Expression ')'
> >
> > Where "Identifier" represents a final local variable valid in the scope of
> > "Block" or "Expression"
> > with the function (or SAM) type of a lambda expression. The factorial
> > example would then read:
> >
> > #int(int) factorial =  #fact(int i)(i == 0 ? 1 : i * (int) (fact.(i - 1)));
> >
> > This would enable referencing outer instances of lambda expressions from
> > within nested lambda
> > expressions, a feature not possible with anonymous inner classes today.
> >
> > The optional "Identifier" could be used for other purposes:
> >
> >    break Identifier;  // non-value-bearing break from the statement lambda
> >    break Identifier : Expression;  // value-bearing break from the
> > statement lambda
> >
> > In addition, if we make lambdas Serializable, the identifier could help
> > determine the name of the
> > class (or a method if java.dyn.MethodReference is used for implementation)
> > generated by the
> > compiler so that moving lambda expression around within the code doesn't
> > break serialization.
> >
> > Regards, Peter
> >
> 
>