Why does compareTo return an integer

Question

I recently saw a discussion in an SO chat but with no clear conclusions so I ended up asking there.

Is this for historical reasons or consistency with other languages? When looking at the signatures of compareTo of various languages, it returns an int.

Why it doesn't return an enum instead. For example in C# we could do:

enum CompareResult {LessThan, Equals, GreaterThan};

and :

public CompareResult CompareTo(Employee other) {
    if (this.Salary < other.Salary) {
         return CompareResult.LessThan;
    }
    if (this.Salary == other.Salary){
        return CompareResult.Equals;
    }
    return CompareResult.GreaterThan;
}

In Java, enums were introduced after this concept (I don't remember about C#) but it could have been solved by an extra class such as:

public final class CompareResult {
    public static final CompareResult LESS_THAN = new Compare();
    public static final CompareResult EQUALS = new Compare();
    public static final CompareResult GREATER_THAN = new Compare();

    private CompareResult() {}
}  

and

interface Comparable<T> {
    Compare compareTo(T obj);
}

I'm asking this because I don't think an int represents well the semantics of the data.

For example in C#,

l.Sort(delegate(int x, int y)
        {
            return Math.Min(x, y);
        });

and its twin in Java 8,

l.sort(Integer::min);

compiles both because Min/min respect the contracts of the comparator interface (take two ints and return an int).

Obviously the results in both cases are not the ones expected. If the return type was Compare it would have cause a compile error thus forcing you to implement a "correct" behavior (or at least you are aware of what you are doing).

A lot of semantic is lost with this return type (and potentially can cause some difficult bugs to find), so why design it like this?

Answer 1

[This answer is for C#, but it probably also apples to Java to some extent.]

This is for historical, performance and readability reasons. It potentially increases performance in two places:

1. Where the comparison is implemented. Often you can just return "(lhs - rhs)" (if the values are numeric types). But this can be dangerous: See below!
2. The calling code can use <= and >= to naturally represent the corresponding comparison. This will use a single IL (and hence processor) instruction compared to using the enum (although there is a way to avoid the overhead of the enum, as described below).

For example, we can check if a lhs value is less than or equal to a rhs value as follows:

if (lhs.CompareTo(rhs) <= 0)
    ...

Using an enum, that would look like this:

if (lhs.CompareTo(rhs) == CompareResult.LessThan ||
    lhs.CompareTo(rhs) == CompareResult.Equals)
    ...

That is clearly less readable and is also inefficient since it is doing the comparison twice. You might fix the inefficiency by using a temporary result:

var compareResult = lhs.CompareTo(rhs);

if (compareResult == CompareResult.LessThan || compareResult == CompareResult.Equals)
    ...

It's still a lot less readable IMO - and it's still less efficient since it's doing two comparison operations instead of one (although I freely admit that it is likely that such a performance difference will rarely matter).

As raznagul points out below, you can actually do it with just one comparison:

if (lhs.CompareTo(rhs) != CompareResult.GreaterThan)
    ...

So you can make it fairly efficient - but of course, readability still suffers. ... != GreaterThan is not as clear as ... <=

(And if you use the enum, you can't avoid the overhead of turning the result of a comparison into an enum value, of course.)

So this is primarily done for reasons of readability, but also to some extent for reasons of efficiency.

Finally, as others have mentioned, this is also done for historical reasons. Functions like C's strcmp() and memcmp() have always returned ints.

Assembler compare instructions also tend to be used in a similar way.

For example, to compare two integers in x86 assembler, you can do something like this:

CMP AX, BX ; 
JLE lessThanOrEqual ; jump to lessThanOrEqual if AX <= BX

or

CMP AX, BX
JG greaterThan ; jump to greaterThan if AX > BX

or

CMP AX, BX
JE equal      ; jump to equal if AX == BX

You can see the obvious comparisons with the return value from CompareTo().

Addendum:

Here's an example which shows that it's not always safe to use the trick of subtracting the rhs from the lhs to get the comparison result:

int lhs = int.MaxValue - 10;
int rhs = int.MinValue + 10;

// Since lhs > rhs, we expect (lhs-rhs) to be +ve, but:

Console.WriteLine(lhs - rhs); // Prints -21: WRONG!

Obviously this is because the arithmetic has overflowed. If you had checked turned on for the build, the code above would in fact throw an exception.

For this reason, the optimization of suusing subtraction to implement comparison is best avoided. (See comments from Eric Lippert below.)

Answer 2

_{Let's stick to bare facts, with absolute minumum of handwaving and/or unnecessary/irrelevant/implementation dependent details.}

As you already figured out yourself, compareTo is as old as Java (Since: JDK1.0 from Integer JavaDoc); Java 1.0 was designed to be familiar to C/C++ developers, and mimicked a lot of it's design choices, for better or worse. Also, Java has a backwards compatibility policy - thus, once implemented in core lib, the method is almost bound to stay in it forever.

As to C/C++ - strcmp/memcmp, which existed for as long as string.h, so essentially as long as C standard library, return exactly the same values (or rather, compareTo returns the same values as strcmp/memcmp) - see e.g. C ref - strcmp. At the time of Java's inception going that way was the logical thing to do. There weren't any enums in Java at that time, no generics etc. (all that came in >= 1.5)

The very decision of return values of strcmp is quite obvious - first and foremost, you can get 3 basic results in comparison, so selecting +1 for "bigger", -1 for "smaller" and 0 for "equal" was the logical thing to do. Also, as pointed out, you can get the value easily by subtraction, and returning int allows to easily use it in further calculations (in a traditional C type-unsafe way), while also allowing efficient single-op implementation.

If you need/want to use your enum based typesafe comparison interface - you're free to do so, but since the convention of strcmp returning +1/0/-1 is as old as contemporary programming, it actually does convey semantic meaning, in the same way null can be interpreted as unknown/invalid value or a out of bounds int value (e.g. negative number supplied for positive-only quality) can be interpreted as error code. Maybe it's not the best coding practice, but it certainly has its pros, and is still commonly used e.g. in C.

On the other hand, asking "why the standard library of language XYZ does conform to legacy standards of language ABC" is itself moot, as it can only be accurately answered by the very language designed who implemented it.

TL;DR it's that way mainly because it was done that way in legacy versions for legacy reasons and POLA for C programmers, and is kept that way for backwards-compatibility & POLA, again.

_{As a side note, I consider this question (in its current form) too broad to be answered precisely, highly opinion-based, and borderline off-topic on SO due to directly asking about Design Patterns & Language Architecture.}

Answer 3

This practice comes from comparing integers this way, and using a subtract between first non-matching chars of a string.

Note that this practice is dangerous with things that are partially comparable while using a -1 to mean that a pair of things was incomparable. This is because it could create a situation of a < b and b < a (which the application might use to define "incomparable"). Such a situation can lead to loops that don't terminate correctly.

An enumeration with values {lt,eq,gt,incomparable} would be more correct.

Answer 4

Reply this is due to performance reasons. If you need to compare int as often happens you can return the following:

Infact comparison are often returned as substractions.

As an example

public class MyComparable implements Comparable<MyComparable> {
    public int num;

    public int compareTo(MyComparable x) {
        return num - x.num;
    }
}

Answer 5

My understanding is that this is done because you can order the results (i.e., the operation is reflexive and transitive). For example, if you have three objects (A,B,C) you can compare A->B and B->C, and use the resulting values to order them properly. There is an implied assumption that if A.compareTo(B) == A.compareTo(C) then B==C.

See java's comparator documentation.