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?
@Jochen:
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
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
