Addition to Comparable interface

Reinier Zwitserloot 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  
happened?)

  --Reinier Zwitserloot



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  
>>> compareTo
>>> 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  
> are
> known to be positive.
>
> Mark Thornton
>
>




More information about the coin-dev mailing list