Lambda expression as a succinct way to pass in type parameter

Zhong Yu zhong.j.yu at gmail.com
Mon Nov 14 11:57:46 PST 2011


On Mon, Nov 14, 2011 at 11:47 AM, Rémi Forax <forax at univ-mlv.fr> wrote:
> On 11/14/2011 06:29 PM, Zhong Yu wrote:
>> Hi Brian, I think I have an interesting use case, but I need your
>> confirming that it's viable. Consider a method
>>
>>      <T>  T foo() {...}
>>
>> Suppose the body of foo() needs to know the runtime value of T, due to
>> erasure, we must pass in a construct containing the value of T
>>
>>      <T>  T foo(TypeToken<T>  type) {...}
>>
>>      interface TypeToken<T>
>>      {
>>          int f(int x); // not really used
>>      }
>>
>> We can call foo() this way
>>
>>      Bar result = foo(x->x);
>>
>> The lambda expression x->x is compiled into an object of
>> TypeToken<Bar>, and the body of foo() can use reflection to retrieve
>> T=Bar.
>>
>>      // equivalent code
>>      Bar result = foo(type);
>>
>>      static TypeToken<Bar>  type = new TypeToken<Bar>(){ public int
>> f(int x){ return x; } }
>>
>> Question: do you see anything wrong with this usage pattern? (other
>> than how odd it looks)
>>
>> cheers,
>> Zhong Yu
>>
>
> Interesting pattern but ...
>
> This may not work because at runtime the reflection will return a class
> that doesn't implements TypeToken<Bar> but TypeToken
> because a lambda implementation may try to reuse the same class for
> several TypeToken.
>
> The idea is that the class that implements TypeToken will not be
> generated by the compiler
> but by the VM at runtime to avoid to generate boilerplate bytecodes on disc
> so the generation will occur after the erasure so Bar information will
> be lost.

That would be a bummer.

>From foo()'s point of view, there is no lambda expression. It sees
only an ordinary TypeToken<T> argument. foo() can require that the
argument is "decently typed" - no raw super class etc. If lambda
expressions are not "decently typed", caller must not pass a lambda
expression to foo().

Suppose a method parameter type is a SAM interface, we must then
document whether a lambda expression argument is acceptable. That
depends on how the method uses the argument. If the method does
nothing but invoking the single abstract method, obviously lambda
expression is acceptable. But beyond that, what kinds of usages of the
argument makes lambda expression unacceptable? Where's the line that
differentiate lambda expressions from "classical" objects?

Zhong Yu


More information about the lambda-dev mailing list