Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.8-beta-1
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Environment:Windows XP
-
Number of attachments :
Description
I've found some strange behaviour when dynamically overriding methods that are called in a class hierarchy, which I think might be a bug. The problem is that when I override a method on a subclass, code in the superclass still calls the original method (note all classes are Groovy ones, I know this wouldn't work with a Java class hierarchy).
I've isolated it to this sample code:
class BaseClass {
def baseClassMethod() {
println "BaseClass.baseClassMethod()"
internalMethod()
}
def internalMethod() {
println " BaseClass.internalMethod()"
}
}
class SubClass extends BaseClass {
def subClassMethod() {
println "SubClass.subClassMethod()"
internalMethod()
}
}
def subClass = new SubClass()
subClass.metaClass.internalMethod = { -> println (" (dynamic).internalMethod()")}
subClass.baseClassMethod()
subClass.subClassMethod()
...which gives me the following output...
BaseClass.baseClassMethod()
BaseClass.internalMethod()
SubClass.subClassMethod()
(dynamic).internalMethod()
I would have expected that the dynamic version of internalMethod() would be called both times, given that Groovy has dynamic method dispatching.
Some discussion of this issue took place on the mailing list: http://old.nabble.com/Problems-using-metaClass-to-override-methods-in-class-hierarchy-td26743895.html#a26743895
The suggestion is that the CallSiteArray.createCallCurrentSite(...) method could check whether the receiver is a sub class of the sender class.
Activity
Hi everyone.
We're having some problems using metaClass to override methods in a subclass for unit testing, and I think it's related to this problem.
Attached are some unit tests that illustrate the issue. We have an abstract class that we want to test, and we use a test wrapper class to help out. We can't override the abstract class' methods effectively because any calls within the base class ignore metaClass, unless the code is executed within a Closure.
So there's an ugly, ugly workaround at least... 
added code tags