Lambda Conversion Considered Harmful?

[Peter Levart]

From the 0.1.5 spec:

On Saturday 13 February 2010 02:21:38 Alex Buckley wrote:
> [5.2] Assignment Conversion
> 
> Assignment contexts allow the use of one of the following:
> - a lambda conversion (5.1.14).
> 
> [5.3] Method Invocation Conversion
> 
> Method invocation contexts allow the use of one of the following:
> - a lambda conversion (5.1.14).
> 
> /*
> Implementing lambda conversion will likely generate new objects to
> wrap or delegate to the lambda expression. This is acceptable in
> assignment and method invocation conversion contexts, but not in a
> casting conversion context. (See
> http://mail.openjdk.java.net/pipermail/lambda-dev/2010-January/000449.html)
> */
> 

I don't think we can allow assignment contexts or method invocation contexts to perform 
conversion if the conversion is to SAM classes (not interfaces) which wrap function objects. The 
abused TimerTask example from above URL could be rewritten to exhibit those two conversion 
contexts to produce misleading source code.

This is the original example:

    Timer timer = new Timer();
    #void() task = #() { ....; ((TimerTask)this).cancel(); }
    timer.schedule((TimerTask)task, 1000L, 1000L);

Now, if only casting conversion wasn't allowed, one could write this:

    Timer timer = new Timer();
    #void() task = #() { ....; TimerTask tt = this; tt.cancel(); }
    timer.schedule(task, 1000L, 1000L);

So if we disallow assignment conversion too, one could write this:

    static void doCancel(TimerTask tt) { tt.cancel(); }
    ...
    Timer timer = new Timer();
    #void() task = #() { ....; doCancel(this); }
    timer.schedule(task, 1000L, 1000L);

All above examples are misleading if each conversion to SAM class instantiates new instance.

I think we have to disallow conversion to SAM classes (if implemented by wrapping function 
objects).

Regards, Peter