ProtoObject and comparison for equality and ordering

[H. S. Teoh]

On Wed, May 15, 2019 at 11:14:17AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 5/15/19 4:09 AM, Jonathan M Davis wrote:
> > Except that this DIP doesn't need to define opCmp's signature - at
> > least not if it's not including interfaces in the design. The rules
> > for opCmp's signature on classes should be able to be the same as it
> > is for structs.  Classes derived from a class that defines opCmp
> > will be restricted by the signature on the base class, but the base
> > class should be able to define an opCmp the same way that a struct
> > would, meaning that any spec changes that we might want to make
> > about what opCmp returns or accepts should be able to be completely
> > separate from this DIP.
> 
> It seems that could work real neat.

Yeah, I think that's the right way to go.  Don't impose any specific
signature on opCmp, and let the user derive a base class with whatever
desired signature he wants, be it int opCmp(), or float opCmp(), or
OverlyElaborateOpCmpResult opCmp().  As long as the compiler can
translate x < y to x.opCmp(y) < 0 and have it compile, that's Good
Enough.


> One thing that bothers me is inheritance. It seems to me most of the
> time just inheriting opCmp and opEquals does not work - they'd need to
> be overridden to account for the added state. However, sometimes they
> _do_ just work. So I'm in two minds on whether inheriting but not
> overloading those two should be an error or not.

How would you enforce it, though?  If we go the compile-time
introspection route, that means user base classes that define opCmp can
define whatever they want, including allowing derived classes to simply
inherit base class opCmp.  It wouldn't be ProtoObject's responsibility
to enforce any policies concerning opCmp -- it'd be up to the user to
get it right.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.