Hi all,
Groovy categories are used to temporarily "shadow" existing methods on a
class. That means if a class has a method toString() and my category
defines for this class a toString() method, then the one of the active
category is used instead of the implementation in the class. A method
can also be added through a category, but again this is not lasting.
Groovy categories allow the user to "shadow" methods in a thread local
context. That means if toString is replaced and I call a method while
the category is active and this method uses a toString method that my
category shadows, then the toString version of the category is used instead.
So for a call site this means, that a category might be active at one
point in time, but the next time the same callsite is visited the
category might no longer be active... And that is something all call
sites have to manage, because theoretically each of them could meat an
active category. That also means that if we use invokedynamic that we
need to check for this.
I now assume we have a mechanism in Groovy that allows us to request a
method handle for the normal case without category
> MethodHandle target = runtime.getMethod(callerClass, receiverMetaClass,
> methodName, arguments)
and we also have a test if an category is active
> boolean isCategoryActive = runtime.isCategoryActive(receiverClass, methodName)
and of course a method to get the meta Class
> MetaClass mc = runtime.getMetaClass(object)
This design is more or less open for improvement as long as the
semantics of the categories are not changed.
Now in a naive call site caching implementation the algorithm would look
like this:
> boolean isCategoryActive = runtime.isCategoryActive(receiverClass,
> methodName);
> MethodHandle mh = callsiteXY.target;
> if (isCategoryActive) {
> mh = runtime.getMethod(callerClass, receiverMetaClass, methodName,
> arguments);
> }
> mh.invoke(...)
(this is a very condensed form, I hope it is still readable)
My question now would be how an implementation would look like if
invokedynamic is used here.
The spec talks about guards, but their usage is not very clear to me.
Let me assume that I use guards to implement this. Then the target
method will be the one from the original class. The guard will do the
test and fallback will be used... well for what. The spec is open about
this. I assume fallback will be used to... hmm... well to do what?
If the idea is to use fallback instead of target (which I assume), then
what happens to target? Does this mean that the next time this call site
is visited the guards will again test and target will be executed if the
category is no longer active? If I think about a category used while a
loop performs this does not sound very fast. In fact this sounds as if
it will be even slower than "normal" invocation with fallback directly,
because in that case no guards will be executed. Or is there a way to
"switch"?
bye Jochen
--
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 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
-~----------~----~----~----~------~----~------~--~---
