I am missing something: > Core methods are in MethodHandle. Others are in MethodHandles. > from the implementation point of view, core method can be implemented > differently depending on the kind of MethodHandle; > Also, having a lot of virtual methods as a cost in memory which can be > important if the all method handle kinds are subtype of MethodHandle.
There is only one copy of the instance method table per class (in this case methodHandle type), so I don't see that the overhead of extra instance methods is that great. -- Howard. On 9 March 2011 10:26, Rémi Forax <[email protected]> wrote: > On 03/09/2011 12:15 AM, Howard Lovatt wrote: >> R?mi Forax<[email protected]> wrote: >>> Hi Howard, >>> thank you for your comments. >>> >>> On 03/07/2011 12:25 AM, Howard Lovatt wrote: >>>> The new API looks great. I think all the simplifications made, >>>> particularly around CallSite and no longer having a Bootstrap, have >>>> really helped. The methods isWrapperInstance, wrappedInstanceTarget, >>>> and wrapperInstanceType are nice additions to the API. >>>> >>>> The requirement that a SAM (in MethodHandles.asInstance( ... )) must >>>> be public and must by an interface is a bit restrictive. Could either >>>> or both limitations be removed earlier rather than latter? >>> There are really few issues, we are still talking. asInstance is one of >>> them. >>> because specifying it is not that easy. >>> Supporting abstract class is even more tricky. >>> Moreover supporting abstract class requires a constructor without argument >>> thus make asInstance() not useful for a lot of abstract classes. >> One possibility is to add extra asInstance methods: >> >> asInstance( MethodHandle target, Class<T> abstractClass, MethodType >> constructorTypes, Object... args ) >> asInstance( MethodHandle target, MethodHandle constructor, Object... args ) >> >> So that the correct constructor can be selected and arguments passed to it. >> >> More general comments on the API: >> >> 1. Replace all the static methods in MethodHandles that have a target >> as their argument (typically first), e.g. asInstance, with instance >> methods in MethodHandle. It makes the API much easier to use. > > Core methods are in MethodHandle. Others are in MethodHandles. > from the implementation point of view, core method can be implemented > differently depending on the kind of MethodHandle; > Also, having a lot of virtual methods as a cost in memory which can be > important if the all method handle kinds are subtype of MethodHandle. > >> 2. Add methods to extract the class that the method was looked up in >> and name of the method to MethodHandle, e.g. getLookupClass() and >> getName(). These are useful in keeping track of method handles, >> particularly for error reporting. >> >> 3. Add reflect methods to match the unreflect methods for conversion >> from MethodHandles to core reflection. Useful when you need to >> interact with an old API. > > Those two items are open issues for JSR292 v2 :) > >> -- Howard. > > Rémi > > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- -- Howard. _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
