Whenever you load a class that could be equal to other sibling classes, re-define the comparison function by wrapping the old comparison function in a new function definition that handles the sibling cases, and calls the old function for all other cases.

I told you it was horrible and ugly.

I think that, at the end of the day, comparison can not be a member function. Certainly in closed languages like Java, C++, and Ocaml, where the entire implementation of the class has to be present when initially declared, the information needed to write a comparison class simply isn’t available when you’re writting any given class. Note that both derived classes need to know about the other derived class, because you can’t tell if equals will be called as derived1.compareTo(derived2), or derived2.compareTo(derived1).

But even in open languages like Ruby and Smalltalk, which allow you to add member functions to a class later, I still don’t think compare can be a member function, because you need too much flexibility. Say we have a base class and three derived classes, and want to have three different data structures- one holding derived classes one and two, one holding derived classes one and three, and one holding derived classes two and three. Now you need three different comparison routines, each copied into two different classes!

Your original solution — which has been (and will probably continue to be) my own default solution — was what I was working with when I first encountered this problem. It’s the standard solution I’ve seen kicking around in Dietel/Deitel/whatever and other places. I just looked into my “Java Cookbook”, and it’s the solution they model right there (p226).

The problem I encountered was simplified to the 2D/3D case. That case illustrates the asymmetric return values that pop up even in a trivial case of polymorphism, resulting in arbitrary behavior by the Set class.

So far, my only conclusion has been that one should never try to use equals(Object) if the objects aren’t of precisely the same class. This means that you can’t have Map keys or Set values made up of different classes, and being the same “abstract class” or implementation the same interface aren’t good enough.

The fundamental problem is that it makes no sense for “equals” to be defined as an instance method, because implicit to the question of “equals” is “equals in terms of what”?

Again, consider the 2D and 3D point example, which is literally a textbook example of polymorphism and reuse — the 2D point, however, will hapilly return “true” if it is asked if it is equal to the 3D point. The 3D point, being aware of more state, will return “false” if it asked if it is equal to the 2D point. This example trivially shows that one of the fundamental guarantees requried of the equals(Object) method — that a.equals(b) == b.equals(a) is true — cannot be defined in a simple way when polymorphism is in effect. You need to use the EqualsBuilder.reflectionEquals(this, that) style of coding, but then you’re carrying forward those issues we saw before.

And you still don’t have a good case where two classes both implement an abstract base class or interface. For instance, it would be reasonable to see code where you have maps of maps (any Perl-turned-Java programmer has written thos code). If you accept abritrary maps, however, it’s very possible that the a.equals(b) == b.equals(a) requirement could b violated given different implementations of a and b — for one thing, any Map relying on EqualsBuilder would fail when presented with a non-related implementation of Map.

All of which throws the problem back into the user’s lap.

The fundamental problem isn’t that nonsensical things are being compared — it’s that whether two things are “sensical” for being compared is an abstract phrase. The problem is that Java isn’t functional enough to realize that it needs to be able to define “Equals in terms of…” for basically any data structure.

s/equals/compare to/g for another fun argument.