I would like to discuss the MethodHandles factory

[Fredrik Öhrström]

John Rose skrev:
> On May 27, 2009, at 9:16 PM, Charles Oliver Nutter wrote:
>
>   
>> we *must* give the keys to the castle to language
>> developers, by opening up the very guts of the JVM's optimizing
>> pipeline
>>     
>
> I agree that static type checking for method handles would be very  
> useful, but the language design work is difficult and subtle.
>
> As method handles become useful, they may tip the scales in favor of  
> adopting more (or all) of Neal Gafter's closures proposals.
>
> If Neal's design is adapted so that that various function-type  
> interfaces are not guaranteed to reify a closure's type at runtime, I  
> think we could fit method handles under closures.  I'm not sure how  
> much of a distortion that would be; there will be some.
>
> So this:
> 	x instanceof {int => String}
> would translate to something like
> 	x instanceof MethodHandle
> 	&& ((MethodHandle)x).type()
> 		.isAssignableTo(MethodType.make(String.class, int.class))
>
> And {int => String}.class would either be illegal or produce an  
> interface with lots of special magic treatment.
>
> Or maybe {int => String}.class would be a MethodType.  As I said, some  
> distortion is likely.
>   
Yes, some distortion is likely. But MethodHandles are so close to
closures (no pun intended) that it would be a waste, not to use them. I
have been thinking about the relationship between MethodHandles,
closures and stored messages, here:
http://blogs.oracle.com/ohrstrom/2009/08/using_methodhandles_to_reconci.html

Closures can even be useful for the dynamic language runtime developer! :-)

//Fredrik