Am 08.03.2015 18:39, schrieb Peter Levart:

On 03/08/2015 01:38 PM, Jochen Theodorou wrote:
Am 08.03.2015 12:16, schrieb Remi Forax:
You need to restrict the set of method handles that are allowed to be
installed inside a CallSite corresponding to such kind of invokedynamic.
Something like: you can do any transformations you want on the arguments
but not on the receiver (no drop, no permute, no filter) and then you
need to call unconditionally a method handle created using findSpecial
on the super class.

unconditionally, like no guard?


There can be GWT, but it can only select one of target/fallback that are
both from the restricted set of MHs.
So Jochen, can you point me to an algorithm used for MultiMethods
dispatch in Groovy and I'll try to prepare a proof-of-concept that uses it?

You can use the Java dispatch rules, only that you take runtime types for receiver and arguments, instead of the static ones. I suggest you also ignore vargs (life is complicated enough). Groovy does some more conversions and other fancy stuff, but I think the above is already complicated enough, especially because you have to solve the problem of a fallback that has to cause a new method selection. If you can solve that problem, then I see use for super-init-calls with that style.

So far we have to install a "dispatcher" handle through the static callsite bootstrapper, because of the lack of runtimetype information. Which then will do the actual method selection of course. That means the first handle we install is not the target and the first invocation of the real target method is done from inside my runtime in the dynamic bootstrapper, since I cannot simply fallback to the static case anymore. It is the same for any case in which the guards for checking the runtime types fail. A PIC should have similar problems.

bye Jochen

Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit

mlvm-dev mailing list

Reply via email to