Updated State of the Lambda

[Gernot Neppert]

2010/10/19 Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
> Hi Gernot,
>
>>
>> Merely prefixing 'cancel' with 'this' will now cause the TimerTask to
>> cancel the entire timer instead:
>>
>
> not quite, this.cancel() and cancel() [unqualified] both refers to
> MyClass.cancel - in the latter case the reference to the 'right' this will
> simply be inferred by the compiler, as already happens with Java. But, from
> the compiler perspective, there's no TimerTask.cancel() available inside the
> lambda body - in order to call that you should use the DA/DU trick discussed
> yesterday:
>

I see what you mean, thanks for the clarification!
(which will also interest Reinier Zwitserloot whom I cited in my first post).

However, I see another problem with the approach:
If the only way to access members of the SAM itself from a within
lambda is via the reference that it will get assigned to,
we'll run into trouble with visibility rules!
See the following example. Provided that the rules for final
assignment will have been updated, the following should compile.
The lambda expression wants to make use of the protected
'totallyUsefulHelperMethod()' defined in the abstract base class
'Sam'.
However, it can't, because it does not have access to protected
methods of other instances (even though we know that it's supposed to
be the same instance in this case).
This would mean that we could never make use of protected methods of
abstract base classes in lambdas.

What do we do?


package net.lambdas;

public abstract class Sam implements Runnable
{
    protected final void totallyUsefulHelperMethod()
   {
   }
}

package net.lambdas.test;

public class TestSam
{
   public void testSam()
   {
      final Sam s = #{  s.totallyUsefulHelperMethod(); };
   }
}