Fun with method references

[Brian Goetz]

They are type checked at runtime, making them dynamically type-safe.  However, 
both generics and MHs have the problem that you could not overload methods 
whose arguments are function types; since under either scheme

   foo({ String => int } stringHandler) { ... }
   foo({ Bar => int } barHandler { ... }

could not be overloaded since they would have the same erasure.  But users 
would find it a very confusing restriction (especially if the scheme did 
permit overloading on arity, as some function-to-generics mappings permit.)

This restriction really makes surfacing function types a non-starter at this 
point.



On 8/6/2010 4:26 PM, Nathan Bryant wrote:
> I'd thought that MethodHandles were type checked at runtime, and that
> function types built on top of them could also express primitives.
>
> Perhaps you are reacting to the "round trip through generics" aspect of
> the presentation that's recently been referred to, or that some of the
> proposals to date have implemented function types as translation to
> generic SAMs named Function0, Function1, etc. But surely this is not the
> only possible implementation choice.
>
> -----Original Message-----
> From: Brian Goetz [mailto:brian.goetz at oracle.com]
> Sent: Friday, August 06, 2010 4:22 PM
> To: Nathan Bryant
> Cc: Neal Gafter; lambda-dev at openjdk.java.net
> Subject: Re: Fun with method references
>
> Adding non-reified function types would be even worse in that regard.
>
> On 8/6/2010 4:20 PM, Nathan Bryant wrote:
>> It also makes the transition to reified generics worse, by adding new
>> non-reified types to the standard library.
>>
>> Neal Gafter wrote:
>>> Adding SAMs now instead makes the transition to function types worse.
>>
>>