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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
