> > Other languages (most? all?) separate equality and ordering for this > reason.
Java doesn't really separate them. Their `==` always checks object reference so is like PHP's ===. But they do have the .equals() method on all objects (our ==) and the collections use that for equality. In these schemes I am not understanding how to specify that something > is not equal, not ordered, and should not fall back to something else. > Consider things like UUIDs and other identifiers where equality is > desired and ordering does not make sense. For something to be not equal, you return anything but 0. If something is not ordered, you return -1 (LHS wins). If you don't want something to fall back to any default behaviour, just return an integer and not NULL. The realistic case, in my opinion, is that there will always be *some* property to order by, whether it's the object's numeric value, a string that can be alphabetical, or a time based element. We can argue that if the object doesn't have a defined, logical ordering, then it also wouldn't make sense to order a collection of them in the first place. So with that in mind, maybe it's okay to take "NULL falls back to default behaviour" idea out, and do a normalisation on whatever the user returns. If it's NULL, then that'll be 0, and the value will be equal. The only thing I don't like about that is that the user didn't specify "equal" with a 0, they returned the absence of a direction, and we should therefore either throw an exception internally, or fall back to the current comparison behaviour (comparing properties). The NULL return is a special case for me. Anything else is *some* value that can be normalised ($v ? ($v < 0 ? -1 : 1) : 0). Therefore, I believe it comes down to a simply question: how do we handle the case where __compareTo returns NULL?
