Checking pre-conditions of pull up method refactoring

[tsdh]

I don't see how the pre-conditions of the pull up method refactoring can be checked on the PG because the information on having "equivalent functionality" isn't contained in there.

Example:

class A {}
class B extends A {int foo() {return -1;}}
class C extends A {int foo() {return 1;}}

Here, B and C have a common superclass and their foo methods have identical signatures and access no members of B or C, so the foo method is a candidate for pulling up. However, they don't have equivalent functionality. That's not checkable in the PG. How to deal with that?

One could try to check that by going back to the original Java code/AST in order to check if the method bodies are equal. But that would require that you have to define an equality operator for any AST class whose instances might occur in a method body and that's almost everything. (You might be better off if you can serialize the bodies back to Java, canonicalize them, and then compare the strings but AFAICS at least JaMoPP which I use here doesn't seem to have that functionality as part of its public API.)

Another problematic example is:

class A {}
class B extends A {abstract int foo();}
class C extends A {int foo() {return 1;}}

Again, the foo method is a candidate for pulling up. But from a programmer's POV pulling up according to the case description is wrong here. It might be ok to pull up the abstract method but the concrete implementation in C must not be deleted. But there are no modifiers anymore in the PG.

[SvenPeldszus]

The decision whether two method implementations are equal is a decision made by the developer who assigned the refactoring. (In our case who designed the test case)

This decision is even with much more information than contained in the PG undecidable.

Accordingly there are no test cases provided by us in which the equality of method definitions is tested or has to be decided.

[tsdh]

Ok, perfect.