Charles Oliver Nutter schrieb: > Jochen Theodorou wrote: >> On further thought I have some questions here... is it possible to have >> custom MethodHandles? Custom in the sense of extending MethodHandle... >> if not, then I am not sure how types are converted. For example I do >> >> foo.bar(x) >> >> where bar on foo takes a String and x is a GString. Normally I need to >> coerce the argument into a String using toString. But I never understood >> how I do apply this kind of transformation. > > The current API has ways of adapting method handles to spread arguments, > collect arguments, convert arguments, curry additional arguments, and so > on. Much of that is not implemented yet, but I think there's infinite > ability to composite method handles together into a single handle you > can insert into the callsite. So once you think of the method call > process in terms of a functional decomposition, it becomes pretty easy.
I guess I just don't understand all details yet. [...] >> I also never understood why the bootstrap method must make the call... >> why not letting it produce the handle? > > I think this might be an option, or at least allowing the bootstrap > method to subsequently invoke the handle it has created. This will allow > it to participate more directly in the process, rather than (as in > JRuby's invokedynamic support) having to re-do essentially the same > logic it just bootstrapped in order to make the first call. calling the handle should be possible.. what I dislike is that the bootstrap has to do this... well I guess it is because then you can decide to cache or not to cache... would a handle that invalidates the cache after the call to be too problematic? >> Now the problems I have with this are simple... I need loads of custom >> method handles for many types I have to transform. I understand that the >> annonymous class loader is probably the idea to handle this. Also I >> think this here will add a stack frame, or not? that's something I don't >> want to have, because of first because of Hotspot and second because of >> method like Class.forName(String). > > Think functional decomposition; your adapter handles would call a series > of additional functions that manipulate the argument list, eventually > calling the "real" handle. I believe this all gets removed from the call > stack, or at least in the currying case I have in JRuby I see no > additional frame between the call site and target. currying is different from actually calling a MethodHandle, from within another MethodHandle. I can see how MethodHandles provides currying, but it is not what I would call direct argument stack manipulation. Doe example I can append arguments, but only at the first place. Of course I see problems with long/double, as they take two slots on the stack. But the currying provided by MethodHandles won't help me to get the job done. What does insertArguments help me, if I need the value to all this? The value is a per call value, not a value I can calculate before hand. So I can not use drop/insert to accomplish my goal to convert the GString. bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
