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. In JRuby's preliminary support for invokedynamic, for example, I'm currying the actual Ruby method object into the methodhandle I install, so future calls will go straight to an "invoker" method that takes that Ruby method and calls it with appropriate argument juggling and pre/post-call logic. Eventually I hope to also put that juggling into a method I can composite in as an adapter, ad infinatum, until invokedynamic installs a single adapter that goes all the way from call site to actual method, handling all extraneous bits of logic along the way. > 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. > 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. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
