A fresh look at comparisons

Yigal Chripun yigal100 at gmail.com
Wed Apr 16 09:17:25 PDT 2008


Steven Schveighoffer wrote:
> "Janice Caron" wrote
>   
>> On 16/04/2008, Steven Schveighoffer wrote:
>>     
>>>  IMO, opCmp should be
>>>  defined in an interface, and those classes which implement it should
>>>  implement that interface.  This would prevent trying to compare 
>>> something
>>>  that doesn't implement the opCmp method.
>>>       
>> Of course, you realise that just because you declare "MyClass
>> implements opCmp()", it doesn't necessarily follow that all possible
>> subclasses of MyClass, which may be declared by other programmers, in
>> other modules, at any time in the future, will also implement opCmp().
>> Nor can you be sure that your opCmp() function will be appropriate for
>> all such subclasses.
>>     
>
> Yes, but then there is no 'default' opCmp which does the wrong thing in all 
> cases :)
>
> If a derived class does not implement opCmp, it is the derived class' fault 
> for saying "I'm OK with my parent's opCmp", when it actually isn't.  Not 
> overriding opCmp if defined by a parent class is an unambiguous choice, 
> which fits in with the standard virtual function implementation.  However, 
> in the current version, nobody should EVER use the default opCmp because it 
> simply isn't correct.
>
> I'm not sure that the idea that opCmp should be a virtual function is bad or 
> good.  All I'm saying is that it probably doesn't belong in Object.
>
> -Steve 
>
>
>   

I completely agree and would like to add that maybe there should be two
interfaces: one for partial order comparison, and one for full order
comparison.

Also I don't think D should have yet another special syntax for just one
use case, and I don't think D should limit opCmp to be non virtual. That
should be decided by the programmer (if needed the programmer can use
"final").

--Yigal



More information about the Digitalmars-d mailing list