this should not refer to the lambda

[Rémi Forax]

Le 21/02/2010 17:44, Alex Blewitt a écrit :
> On 21 Feb 2010, at 15:26, Rémi Forax <forax at univ-mlv.fr> wrote:
>
>> Just a last example: I don't want to explain why 'this' doesn't mean
>> the same thing in the two codes:
>>
>> Object[] array = { this };    // here this doesn't refer to the array
>>
>> #Object() fun = #() (this);  // here this refer to the lambda ??
>
> This argument is somewhat tautologous. "I'd have difficulty in 
> explaining it because I don't like what it means".

I have no difficulty to explain it. I don't want to explain it.
There is different way to weight a feature, my way is to try to evaluate
how many hours it will take to explain it.

The other useful metric is in which order you have to explain the feature.
By example, enum is a complex feature in Java because you have to
first explain interface and anonymous class.

I think it's possible to explain lambda *before* anonymous class
as a lightweight anonymous function.

>
>>
> Object o = new Runnable() { void run() { this;} }// this refers to the 
> runnable, not the enclosing object.
>
> The # is a lot more like the Runnable than the block case; you are 
> (potentially) instantiating a new "thing" (it can throw OOM) and that 
> thing has reference semantics, much like an instance would. A block 
> cannot throw an OOM nor does it have reference semantics.
>
> Note that I am not assuming any particular implementation of # but 
> these effects follow from the fact that # may be a closure over local 
> state (thus requiring a binding context to be created) and by virtue 
> that a lambda may be passed around as a reference.
>
> Even if there is a third type of top-level  element added to the 
> language, the it-doesn't-fit-my-mental-model-of-what-I'd-like-it-to-be 
> is not a good reason one way or another. What we have to ensure is 
> that we explain it in a way that people can conceptualise, and to 
> ensure that the # is treated as a psuedo-new operator to ensure that 
> it doesn't become a source of memory leaks.
>
> (I use pseudo-new here because it shouldn't always create a new 
> instance, particularly when no local scope is captured.)
>
> But having a potentially instance-creating, reference based type and 
> then disallowing the use of the operator in Java which is used to 
> refer to self-instances seems (to me) inconsistent with the language 
> as is (though of course, this is about changing the language).
>
> And, as noted elsewhere, the ablility to reference the enclosing type 
> is not hindered in any way if "this" does refer to the lambda. As for 
> the nested lambda case, this is also possible (either implicitly due 
> to local state capture or explicitly) without having to resort to 
> language gymnastics like letting an RHS expression refer to the LHS type.
>
> public class A {
>   public class B {
>     public void foo() {
>       #() {
>         // Need to add this line if needed
>         Object me = this;
>         #() {
> A.this; // A instance
> B.this; // B instance
> me; // outer lambda
> this; // inner lambda
>         }
>       }
>     }
>   }
> }
>
> It seems this doesn't prevent anything and doesn't require self-refs 
> to be designed as:
>
> Object me = #() { me}
>
> There is no other construct in Jaca where you can do:
>
> Object foo = ... foo ...
>
> Since on the RHS foo isn't in scope. And it'll cause merry hell for 
> IDEs which are built to assume that the RHS can't refer to an LHS 
> assignment - a not unreasonable assumption in any language. (This may 
> also break refactoring concepts as well; whilst there will obviously 
> extensions which will be needed to treat lambdas in the general case, 
> the being able to refer to the LHS from the RHS is the primary issue.)
>
> Still, I suppose we couldn't screw up more than generics, so if we do 
> allow RHS to use LHS then it will just be another future pain point 
> for Java programmers of the future.

Alex, try to compile:
int a =a;
and take a look to the error message.

>
> Alex
>

Rémi