ProtoObject and comparison for equality and ordering

[Jonathan M Davis]

On Tuesday, May 14, 2019 5:24:58 PM MDT H. S. Teoh via Digitalmars-d wrote:
> 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.

Even an interface is a problem, because then that locks in the attributes.
Containers and the code in druntime can be templated, and any user code that
can't be templated can operate on a base class that implements opCmp (or
opEquals or whatever function we're talking about) where that base class is
whatever is appropriate for that particular class hierarchy. Code bases
could even still have interfaces with opEquals or opCmp if appropriate. We
just don't want standard interfaces, because that would lock in the
attributes, and not all attributes are going to work for all code bases (a
prime example of that being const; requiring const for opEquals, opCmp,
toString, or toHash would make it so that lazy initialization pretty much
wouldn't work with classes).

By templatizing all of the relevant code in druntime, the attributes will be
inferred, and we can define these functions on classes in the same way that
we do with structs - just with the caveat that any class derived from a
class that defines such a function will be restricted by how the base class
defined it. However, whereas Object forces all D classes to stick to a
particular set of attributes for those functions, they would only be locked
in for that particular class hierarchy, and other class hierarchies could
make other choices. And by having the relevant druntime code be templated,
standard interfaces shouldn't be necessary, whereas if we created such
interfaces, we'd basically be making the same mistake that we made with
Object except with a different set of attributes.

- Jonathan M Davis