Am 11.07.2013 06:09, schrieb Charles Oliver Nutter: [...] > In JRuby, we pass the calling object into every call site to check > Ruby-style visibility at lookup time (we can't statically determine > visibility, and we do honor it). That gets you a bit closer to being > able to get the caller's classloader without stack tricks (though I > admit it does nothing for methods injected into a class from a > different classloader).
If we would need the caller class on a regular base, we would have something for this in Groovy. But since a call can come from anywhere in Java too, the caller class is no information we can depend on. The current implementation does allow us to get the caller class in the call site, but from there it does not go to the place where it is needed, which is inside the method. Any change to make the caller class passed to the method will require bigger and deep changes. The method will need an additional parameter, which means the signature will not match anymore; the method needs to be recognized in its special function; rules for overriding and overwriting have to be defined (including fun with generics); we have to define what to do in case the call is not from a callsite where the call class is available and so on. It is much more for us than only an internal change. It is a conceptional change and the user will have to know about it (including a bunch of new special rules). I don't see so much a problem here for Groovy 3, but 1.x and 2.x have a problem. 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
