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