Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
I can't speak for all languages but Java explicitly says that equals satisfies the criteria to be an equivalence relation. docs.oracle.com/javase/7/docs/api/java/lang/… –  axblount Oct 5 '12 at 17:28
    
I know of no programming language where the conditional equality operator would ever not be symmetric. Now I temper that with the fact that you can override the conditional equality semantics of a class in some languages and break that symmetry if you wished, but that would be a thoroughly unexpected implementation which no one in their right mind would do. –  Jimmy Hoffa Oct 5 '12 at 18:30

4 Answers 4

up vote 7 down vote accepted

Non-symmetric1 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 properties2, but fundamentally it is not an equality relation, and it is dangerous to use it in the context where the equality relation is implied.


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

2 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.

share|improve this answer
    
I like this. However that is the contract for the method equals(object). What if the derived class has an overload of equals, say equals(T)? Would you say that equals(object) where object happens to be of type T, should behave the same as equals(T) and therefore be bound to the cited contract? –  vossad01 Oct 5 '12 at 18:37
1  
@vossad01 Absolutely, it should: passing an object of type T to the equals(object) method should always produce the same result as passing the same object to the equals(T) method. The only difference is that equals(T) can produce the result faster, because it can bypass the type checking (type safety is guaranteed by the compiler). –  dasblinkenlight Oct 5 '12 at 18:41

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.

share|improve this answer
    
Where would is as part of a team maintaining an inherited C# code base. The original author did a mix of overriding Equals, implementing providing strongly-typed overloads of Equals (sometimes implementing IEquatable<>, sometimes not actually overriding equals), and always returning base.GetHashCode(). The HashCode issue was really causing problems so now it returns a constant. There is another bug shown to be a result of the inconsistent equality behavior between the strongly-typed overloads and the the inherited Equals(object) which now I get to fix. –  vossad01 Oct 5 '12 at 18:20

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.