Should Equality be commutative within a Class Hierachy?

Question

It is easy to define the Equals operation in ways that are not commutative. When providing equality against other types, there are obviously situations (in most languages) were equality not being commutative is unavoidable. However, within one's own inheritance hierarchy where the root base class defines an equality member, a programmer has more control.

Thus you can create situations where

(A = B) ≠ (B = A), where A and B both derive from base class T

Substituting the = with the appropriate variation for a given language. (.Equals(_), ==, etc.)

That seems wrong to me, however, I recognize I may be biased by background in Mathematics. I have not been in programming long enough to know what is standard/accepted/preferred practice when programming.

Do most programmers just accept .Equals(_)may not be commutative and code defensibly. Do they expect commutativity and get annoyed if it is not. In short, when working in a class hierarchy, should effort me made to ensure Equality is commutative?

Answer 1

Non-symmetric¹ equals breaks the contract of the operation, spelled out clearly in the documentation (I'm quoting from the Java's documentation, but it remains essentially the same in other languages)

The equals method implements an equivalence relation on non-null object references:

• It is reflexive: for any non-null reference value x, x.equals(x) should return true.
• It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
• It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
• It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
• For any non-null reference value x, x.equals(null) should return false.

These are mathematical properties a relation must have in order to be called an equality relation. A relation can be defined without any of these properties², but fundamentally it is not an equality relation, and it is dangerous to use it in the context where the equality relation is implied.

---

¹ The right term in the context of equality is "symmetric", not "commutative".

² For example, it is very tempting to define equality of floats as "two numbers with the absolute difference less than a small epsilon"; that's a very bad idea, because it breaks transitivity.

Answer 2

I've never seen = defined as "is-a". = means "is equal to", not "is derived from," even in type hierarchies, and "is derived from" is generally implemented with a different operator or function. Where have you seen it implemented the way you describe? Because that's counter-intuitive and just weird.

Most programmers would not accept that idea of "equality". They would call that "compatibility" or "inheritance hierarchy" or something similar that more correctly describes what's going on, but equality is expected to mean "identical," not "compatible." So yes, it is expected to be commutative.

Answer 3

It would depend on how == is defined...

If it is defined only once at the root of the hierarchy then I would expect it to work when comparing any two objects that are of different types but derived from that same root.

If it is (re)defined in subtypes, then I would only trust == to work if the objects are of the exact same type, not just being derived from the same parent.

I don't think I've ever seen (A = B) ≠ (B = A), but if I did I'd probably be annoyed.

Answer 4

I think commutativity in a class hierachy should be ensured, otherwise this would violate the Liskov substitution principle (LSP) which says

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

So if you expect Equality (A == B) and you insert a subtype of B, called C for which the Equality does not hold (A != C) you would cause a violation. Maybe (C == A), but people that use your classes might not expect this behaviour.

For example, I want to use your classes in my program:

public boolean isEqual(B x, B y) {
   return x.equals(y);
}

Say I have two instances, x is of type B and y the subtype B'. How can you or I guarantee that I insert the objects in the right order to the method? That would result in a lot of additional control structures. And If I did not expect this behaviour, it would be difficult to debug.