Addition to Comparable interface
reinier at zwitserloot.com
Tue Mar 31 08:03:20 PDT 2009
This is an API change, not a language change, so by definition you're
on the wrong list for this proposal.
Also, I think it's a bad idea in general. For -writing- the result of
a compare operation, they're great. But for reading, it's an instant
bug. Any code this form:
if ( a.compareTo(b) == Comparator.BEFORE)
is an instant bug, but unless you suggest the novel idea of having
javac actually attempt to find such things and warn on it, which is
very difficult, this is going to cause more pain that it'll solve.
(very difficult because: what if you pass the result of the compare
job to another method, and that method decides to switch on the
result, using the BEFORE/EQUAL/AFTER constants? How do you detect this
On Mar 31, 2009, at 14:31, Mark Thornton wrote:
> Roy van Rijn wrote:
>>>> FEATURE SUMMARY:
>>>> The return value of the Comparable interfae could be made a lot
>>>> clearer if it would have the following static variables:
>>>> public static int BEFORE = -1;
>>>> public static int EQUAL = 0;
>>>> public static int AFTER = 1;
>>> This might give the impression that the only values returned by
>>> are -1, 0, 1 which is certainly not true. The interface only
>>> requires that
>>> the sign of the returned value reflect the ordering.
>> That might be a problem indeed, but the javadoc should still indicate
>> its possible to use any positive and negative integer value.
>> The problem I've seen a lot is the following, even in large corporate
>> programs, when people compare integers like this:
> It is valid for reduced ranges of integers, notably when the values
> known to be positive.
> Mark Thornton
More information about the coin-dev