On 01/24/2012 09:40 AM, John Rose wrote: > On Jan 23, 2012, at 11:26 PM, Charles Oliver Nutter wrote: > >> Oh, that does seem to work...what an ugly hack. And actually, you can >> just use Object.class but cast the resulting return to void, and it >> works. >> >> So basically, I do this: >> >> handler = MethodHandles.constant(Object.class, null) >> handler = MethodHandles.asType(void.class) > The EG considered things like having MethodHandles.constant(void.class, null) > or identity(void.class). > Even identity(methodType(void.class, Throwable.class, String.class)). > There is a certain logic to such things but it didn't feel regular enough, > and users can get the same effect by asType (as you realized). > > Noctarius is right in referring to Void. The MH API treats Void fairly > regularly as the wrapper type for void, with a unique (unit) wrapped value of > null. > >> handler = MethodHandles.dropArguments(0, Throwable.class, String.class) >> >> And then use that as the exception handler. >> >> It's not exactly the no-op I wanted, since it has the cast logic in >> there, but it's close enough. >> >> FWIW, I'm using this in the tests for invokebinder, for testing the >> tryFinally operation: > That binder stuff is great. Next, we want a builder syntax in Java (for more > than just List+Map constants). Plus a little type-system bridge from > Foo::bar and foo->bar to MethodHandle. Then we can compose our method > handles quite swimmingly.
Lambda should provide bridge from Foo::bar to MethodHandle :) > > -- John Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
