A Fresh Look at Comparisons, Take 2

[Janice Caron]

On 18/04/2008, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
> Huh?  I think maybe you meant C to inherit from B?

Oh yeah. That was a typo. Whoops! I should have said

    class C : B
    {
    }


>  I don't really agree that opEquals or opCmp should not be inherited.  I
>  think normal inheritance the way it is now is just fine.

You do? Why?

You obviously understand that if Z is a
great-great-great-great-...-grandchild of A, then it will still use
A's opCmp() function if not overridden? And you're OK with that?



>  You need to have opEquals in Object in order to support hashing.

Please could you elaborate, as I don't understand why this is so?


>  The default opCmp should be redefined to throw an exception.

Again, I ask, why? Why detect something at run-time that could be
detected at compile time?

Moreover, if Z is a great-great-great-great-...-grandchild of A, then
it will use A's opCmp() function - not Object's. Overriding opCmp even
/once/ changes the defaut for the entire heirarchy from that point
down, and at that point, Object's implementation becomes irrelevant.


>  An alternative
>  is that opCmp is defined in an interface.

Yes, that is an alternative. I had thought of that. But then I
realised that orderedness can be detected at compile-time without need
for an interface, so it seemed unnecessary.