Am 02.12.2011 02:59, schrieb John Rose:
[...]
Consider these examples:
*_Example 1:_*
class C {
private f() { }
}
class D extends C {
}
Let's assume class C has an invokedynamic call site for "obj.f()", and
ends up getting an instance of D. Should it be able to invoke C.f()? I
think yes.
I agree, but it is a corner case.
In Groovy we decided that private methods are not inherited. They are a
bit like static per instance methods ;) Anyway, it means that if you do
obj.f(), and obj is an instanceof D, then the call fails, if it is an
instanceof C it works... unless the call is done from inside C. If you
have this.f() in C, then it will call C#f regardless of what is there else.
The idea behind this is that private methods are seen as implementation
methods, thus I don't want them being overwritten. But I may want to see
them outside of the class for unit testing.
Currently we have a discontinuation here, as obj.f() with obj being a D
would fail, but this.f(), in a method of C, but this being an instance
of D would work. This case is supposed to be solved in the next MOP. The
reason why you would want it like this is, for writing equals(Object)
methods.
[...]
Oh wait, but what if the dynamic call site actually specifies C.class
as the type of the 0th argument? Then you could argue the intent of
the program is to invoke C.f()? But why would a class invoke its own
private member using invokedynamic? It probably wouldn't, so I most
likely shouldn't care about the declared type of the receiver at the
call site.
Granted; that's why the less accurate design would be acceptable.
In case of f() this might be true, but there are some thinks to consider.
(1) a language might want to "record" all method invocations. For
example for logging or other things. In Groovy that requires then that
the call is then made through the meta class. At least if no bytecode
transformation of some kind is used to insert logging.
(2) the method might be overloaded (your language needs to support that
of course) and method selection may depend on the parameter type.
One "acid test" of this API would be what I call "Ninja" (Ninja Is Not
Java Anymore), in which every single imperative construct in a Java
program is compiled to an indy instruction, including self-invocations
of private methods. Can it be made to work behaviorally the same as the
normal Java program? It's a challenge. (And a fun one, when you start
injecting non-Java semantics, such as int-overflow-to-BigInteger.)
Well.... that is mostly what I am doing for Groovy
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
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
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.
