Draft proposal: allow the use of relational operators on Comparable classes (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Tue Mar 10 16:57:52 PDT 2009

Replies inline.

--Reinier Zwitserloot

On Mar 10, 2009, at 17:21, Jeremy Manson wrote:

My major concerns with this is how consistent it is with the rest of the system:

1) There is no guarantee that if a < b and b < c, then a < c. This is not true in general in Java.

But Comparator's contract states you should adhere to this. HashMaps/ Sets randomly fail if you screw up the contract, too. The notion that
stuff breaks if you don't adhere to contract so far hasn't been a
powerful enough reason to hold java improvements back.

2) It is inconsistent to have a < b call compareTo(), but to have == not call equals().

And yet that's exactly what happens now with Integer, Double, Float,
Short, Byte, and Long.

3) If a < b means compareTo, and a == b means reference equality, then_ _you can't specify reasonable behavior for <= and >=.

Sure you can. <= means: the compareTo job returns either 0 or a
negative number.

Don't get me wrong, the notion that '==' doesn't mean equality in java
is an unfortunate brainfart I'd love to see fixed, but I see
absolutely no way for this to happen in project coin's scope. There's
also nothing in this proposal that would stop a future fix; in fact,
it sort of sets it up. That's good.

To fix this, we'd have to go back in time and have == mean object equality instead of reference equality. That would be nice, but we can't do it.

That's not an argument against this particular proposal.

Jeremy

On Tue, Mar 10, 2009 at 9:09 AM, Vilya Harvey <vilya.harvey at gmail.com> wrote: I've attached a draft of a proposal to allow classes which implement the Comparable interface to be used as operands for the relational operators. So for example if you had two Strings, a and b, you would be able to write

if (a < b) { ... } instead of if (a.compareTo(b) < 0) { ... } and you could do the same with your own classes as well. Thanks in advance for any feedback, Vil.

More information about the coin-dev mailing list