User defined method handle

[Rémi Forax]

John Rose a écrit :
> On Feb 4, 2009, at 7:38 AM, Rémi Forax wrote:
>
>   
>> It seems it's currently impossible to create a user defined method  
>> handle
>> because the constructor of MethodHandle take a token (Token)
>> which is not accessible to user code.
>>
>> I remember it was a requirement, is this change ?
>>     
>
> Yes, it's a simplifying change the EG discussed a while ago.  It  
> allows the JVM to put more constraints on the format of a MH.
>
> Most use cases for Java method handles are covered by bound method  
> handles (aka curried functions), created with MethodHandles.bind or  
> MethodHandles.insertArgument.
BTW, the Java code of bound method can be simplified.
In my opinion, a bound method handle is a direct method handle plus an 
object
at argument zero.
The others cases need generated Java code loaded by the anonymous
classloader so there is no need to store an argument position in BMH.
>   The only thing you can't do is have an  
> object which is simultaneously a MH and implements some other API  
> (e.g., a method handle and a Lisp S-expression).  If a language wants  
> to treat a non-MH as a MH-callable thing, it needs to wrap a MH around  
> it somehow.  The existing draft APIs should make this easy.
>
> (I think that covers everything.  Or did I miss a use case?)
>   
If you wrap a MH, you lost the multi-polymorphism of "invoke".
But you can bring it back by implementing invokedynamic on the wrapper
to redirect the call to the wrapped MH.

class MHClosure implements Closure {
  private final MethodHandle methodHandle;
  ...

  public static Object bootstrapInvokeDynamic(ClassSite callSite, 
Object... args) {
    MethodHandle mh=(MethodHandle)args[0];
    callSite.setTarget(mh);
    return MethodHandles.invoke(mh, slice(args)); // slice remove the 
first argument
  }
}

Ok this should work.

>   
>> Also I don't understand why MethodHandle inherits from  
>> MethodHandleImpl,
>> it should be the inverse. MethodHandle should be the base class
>> and MethodHandleImpl a subclass for VM method handles.
>>     
>
> Same reason as above:  It constrains the format of *all* method  
> handles in an implementation-private way.
>   
Ok,  I understand.
> -- John
>   
Rémi