C#/Java: Proper Implementation of CompareTo when Equals tests reference identity

Posted by Paul A Jungwirth on Stack Overflow See other posts from Stack Overflow or by Paul A Jungwirth
Published on 2010-03-13T20:11:32Z Indexed on 2010/03/13 20:15 UTC
Read the original article Hit count: 342

Filed under:
|
|
|

I believe this question applies equally well to C# as to Java, because both require that {c,C}ompareTo be consistent with {e,E}quals:

Suppose I want my equals() method to be the same as a reference check, i.e.:

public bool equals(Object o) {
    return this == o;
}

In that case, how do I implement compareTo(Object o) (or its generic equivalent)? Part of it is easy, but I'm not sure about the other part:

public int compareTo(Object o) {
    if (! (o instanceof MyClass)) return false;
    MyClass other = (MyClass)o;
    if (this == other) {
        return 0;
    } else {
        int c = foo.CompareTo(other.foo)
        if (c == 0) {
            // what here?
        } else {
            return c;
        }
    }
}

I can't just blindly return 1 or -1, because the solution should adhere to the normal requirements of compareTo. I can check all the instance fields, but if they are all equal, I'd still like compareTo to return a value other than 0. It should be true that a.compareTo(b) == -(b.compareTo(a)), and the ordering should stay consistent as long as the objects' state doesn't change.

I don't care about ordering across invocations of the virtual machine, however. This makes me think that I could use something like memory address, if I could get at it. Then again, maybe that won't work, because the Garbage Collector could decide to move my objects around.

hashCode is another idea, but I'd like something that will be always unique, not just mostly unique.

Any ideas?

© Stack Overflow or respective owner

Related posts about c#

Related posts about java