A Fresh Look at Comparisons, Take 2

[Steven Schveighoffer]

"Janice Caron" wrote
> On 18/04/2008, Steven Schveighoffer wrote:
>> Yes.  That is a choice of the great-great-great-...-grandchild of A's 
>> author
>>  :)
>
> Hmmm.
>
> I think more bugs are likely to occur as a result of people forgetting
> to supply opCmp() and having the wrong opCmp() called.

I disagree.  Not overriding opCmp seems to me far more common than 
overriding it.  Many times one inherits from a class to change one bit of 
it, a bit that may not affect opCmp.  Should the compiler assume the user 
wants to override opCmp, and do some default action for him?  Or should you 
always have to alias the parent's opCmp?  I have a project, for instance, 
where I've made 10 classes.  None of those classes define opCmp, and the 
project works beautifully without it.

>>  By not overriding opEquals or opCmp, he is saying that if you compare it
>>  with something else, A's implementation is the one to use.
>
> ...or he might have just forgotten, and it could be a bug.

So what?  If he forgot to override f() from the base class that could be an 
error too.  There is no way for the compiler to prevent all bugs.

>>  >>  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?
>>
>> A hashtable works by <snip>
>
> None of which implies that you need opEquals /in Object/. It only
> implies that you need it in any class that needs to do hashing. Again,
> this is a perfect case for explicit.

It is not necessary in Object, but because it CAN be defined by default, why 
not?  This means any object can be a key without any extra code on the 
author's part.  The default opEquals might not be perfect, but it is 
consistent.  The default opCmp is not consistent.

-Steve