Should be IEquatable's Equals() be implemented via IComparable's CompareTo()?

Question

I've been looking for an answer on the internet but all I've found was:

Edit: Added some items in response to the answers

• For IEquatable

  • I'm supposed to overload Equals(), GetHashCode(), == and != together.
  • I'm supposed to reduce redundancy via implementing != via ==.
  • I'm supposed to seal the class

• For IComparable

  • I'm supposed to overload Equals(), GetHashCode(), <, >, <= and >= together.
  • In fact it is recommend to implement IEquatable when doing so
  • Overload the non-generic version of IComparable
  • CompareTo() == 0 should mean Equals() == true

So I've been thinking about this:

public bool Equals(T other)
{
    if ((object)other == null)
    {
        return false;
    }

    return CompareTo(other) == 0;
}

Am I overlooking something or is this ok?

Answer 1

According to Eric Lippert, a former developer on the C# compiler team at Microsoft:

• There are nine ways to do a comparison in C#: < <= > >= == != object.Equals(object) IEquatable<T>.Equals(T) IComparable<T>.CompareTo(T)
• Ideally these should all be consistent with each other. That is, if x == y is true then x < y is false but x <= y and x.Equals(y) are true and x.CompareTo(y) is zero, and so on.

So, in his opinion, "ideally" x.CompareTo(y) == 0 implies x.Equals(y) == true and vice versa.

Eric then provides an example that implements everything using a private helper method:

public int CompareTo(Natural x) { return CompareTo(this, x); }
public static bool operator <(Natural x, Natural y) { return CompareTo(x, y) < 0; }
public static bool operator >(Natural x, Natural y) { return CompareTo(x, y) > 0; }
public static bool operator <=(Natural x, Natural y) { return CompareTo(x, y) <= 0; }
public static bool operator >=(Natural x, Natural y) { return CompareTo(x, y) >= 0; }
public static bool operator ==(Natural x, Natural y) { return CompareTo(x, y) == 0; }
public static bool operator !=(Natural x, Natural y) { return CompareTo(x, y) != 0; } 
public override bool Equals(object obj) { return CompareTo(this, obj as Natural) == 0; }
public bool Equals(Natural x) { return CompareTo(this, x) == 0; }

private static int CompareTo(Natural x, Natural y) { ... }

Answer 2

x.CompareTo(y) == 0 does not imply x.Equals(y) == true.

x.CompareTo(y) == 0 only means that, when sorting elements x and y, the items appear "in the same position"

For example, given the following class:

public class Person
{
    public string Name { get; set;}
    public string Passport { get; set; }
}

var me = new Person { Name = "Diogo Castro", Passport = "12345" };
var someoneElse = new Person { Name = "Diogo Castro", Passport = "67890" }; 

When sorting these two persons by their name (alphabetically), you'd want me.CompareTo(someoneElse) to return 0, since they share the same name. Therefore, the order in which they appear is irrelevant.

However, you'd want me.Equals(someoneElse) to return false, because they are not the same person.

Answer 3

According to a note in IEquatable(T) Interface the IEquatable interface should be used to determine whether two objects are equal or not. According to IComparable(T) Interface the IComparable interface should be used for supporting the comparison of objects in a way to determine the order of them.

So of course you could implement your Equals method as you did but by doing so you create an dependency between two different things. The equality of two objects and their order.

It always depends on how you look at the object itself. It could be (a stupid example, I know) that you specify that two cars are the same if they have the same engine type, same engine power and so on. If you want to order them, you want to order them by maybe comparing just the power of the engine, not the type and everything else. So you could implement Equals to return true if the object itself contains identical values/references and CompareTo if they maybe have only the same power but maybe different engine types, etc..

(Sidenote: That's why I prefer realising comparison with the IComparer(T) Interface.)