ProtoObject and comparison for equality and ordering

[H. S. Teoh]

On Tue, May 14, 2019 at 05:05:02PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 5/14/19 9:37 PM, Mike Franklin wrote:
[...]
> > IMO, objects should only support reference equality out of the box.
> 
> So that means "x is y" works but not "x == y"?

That makes sense to me if x and y are two completely unrelated classes.
Yes they are "related" in the sense that both inherit from ProtoObject,
but they have no meaningful relationship as far as the application
domain is concerned.  If the user wants to compare them, let him
implement the Comparable interface and the corresponding opCmp(). This
shouldn't be in ProtoObject.


[...]
> > I would like to distinguish between reference equality and value
> > equality.  Reference equality, I think, should be done with the `is`
> > operator, and should probably work out of the box. And I like the
> > idea of users opting into any feature.  If users want to support
> > value equality, they should implement `opEquals`.  If they want
> > comparability they should implement `opCmp`.  If they want to
> > support hashability, the should be required to implement a `getHash`
> > or something along that line of thinking.
> 
> Sounds good. If we go with the notion "you can't key a built-in
> hashtable on any class type" that should work.

I think it would make more sense to have to implement a Hashable
interface (defining an opHash and possibly also inheriting from
Comparable if we want to allow AA implementations that require ordering,
e.g., to use tree buckets) for this purpose.  While being able to throw
any arbitrary object into an AA and having it Just Work is kinda nice,
that's an optional extra and we shouldn't be bending over backwards just
to support that.

Besides, realistically speaking, how useful is an AA that may contain
any arbitrary class, where looking up one key might give you a GuiWidget
but looking up a different key gives you a CryptoAlgorithm and looking
up a third key gives you a GeometricShape?  I can't see how such a thing
could be useful in any meaningful way.  I'd expect that if the user
wanted to put two different classes in the same AA he'd at least bother
to define a common base class that implements the appropriate Hashable
interface.


T

-- 
The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst