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

Kevin Bourrillion kevinb at google.com
Thu Mar 12 09:32:44 PDT 2009

On Wed, Mar 11, 2009 at 2:11 PM, Neal Gafter <neal at gafter.com> wrote:

Vilya-

I suspect that if you narrowed the scope of this proposal to just enum types, it would have a much better chance of getting accepted for project Coin.

To the general proposal, I believe the problem of conflicting meanings of <=, >= and == make it a non-starter.

But focusing on enum types sidesteps one set of problems in favor of another. That being that most user-defined enum types do not actually have any logical order, and many that seem to have an order do not actually have that order guaranteed.

For example, in the core Java class libraries (java.lang, util, etc.) I counted ten enums. Not a single one guaranteed what the order of its constants meant. And, there were only two for which you could even imagine an order that makes sense. One is RetentionPolicy -- as long as there is only SOURCE, CLASS, RUNTIME, you can sort of think of them as being increasing. The other is TImeUnit, but if PICOSECONDS are ever added, we have no way of knowing where it would be added. (Adding it in the expected place could break all those users who were somehow depending on the ordinal; they shouldn't have done that, but Sun doesn't like to break anyone whether they should have been doing what they were doing or not.)

For these reasons, I believe that the automatic Comparable-ness of all enums was a mistake -- not a mistake I'm castigating anyone for, but not one that I think we should make even deeper, either.

Adding the < > support would deepen confusion, but also, because only a small number of enums have meaningful order, it means that this language feature fails the "solves actual real-world pain" test.

-- Kevin Bourrillion @ Google internal: http://go/javalibraries google-collections.googlecode.com google-guice.googlecode.com

More information about the coin-dev mailing list