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