Draft proposal: allow the use of relational operators on Comparable classes

[Kevin Bourrillion]

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