inheritance abuse

[Mark S. Miller <mark>]

Date: Mon, 21 Aug 89 14:00:31 PDT
   From: tribble (Eric Dean Tribble)

   Clearly the right solution is to have a mixin that EQ classes
   multiply-inherit from that implements isEqual and hash using identity
   information....

Well, this is certainly A solution.  I really don't think it's worth
paying the complexity of introducing multiple inheritance into our
code for this case.

   Do objects move about in memory?  If so, then identity comparison will
   work, but Identity hashing won't!

Any EQObject that moves about in memory must have some technique for
letting those objects that point at it know about its new location
(since an EQObject can only be in one place at a time).  This
technique can also inform those who depend on its hash value that its
hash value has changed.  The Necromancer suicide note protocol
supports this perfectly.

   One real alternative is to default isEqual and hash to identity
   operations and simply override them in subclasses that have a more
   sophisticated notion.

Yecch!!  I hate having subclasses override defaults defined in
superclasses (though I do this occasionally too).  If Foo is a
subclass of Bar, then foos are bars, and what is defined to be a
property of bars one should expect to apply to all foos.  Subclasses
should enhance functionality in their superclasses, not replace it.

   This builds the identity a=a into the system,
   but that doesn't really bother me.

But you haven't read the book yet!  (We could define the sibling of
EQObject, the class which doesn't define identity such that a=a as:

CLASS(WhimWorshipper,Object) {
    ...
};
)

   On the other hand, as long as we don't use the class distinction as a
   type distinction, I'm not worried.  We could even have xlint++ check
   for this.  Since the dictinction would not be a type distinction, any
   subclass of Object could redefine isEqual and hash to use identity
   operations, and vice-versa.

That's quite interesting.  We could:

#ifndef XLINT
#	define NOT_TYPE
#endif

and then say:

NOT_TYPE CLASS(EQObject,Object) {
    ...
};

in the declaration.  Xlint could then check that EQObject was never
used in a type declaration.  I rather like this.  It removes many of
the bad consequences on inheritance abuse.  Roland?

   AHA.  Here's a different hack that I like better for a variety of
   reasons.  Define a macro IDENTITY_CLASS that expands to the
   definitions of isEqual and hash for classes that distinguish based on
   identity.  This makes it much more like an orthogonal property and
   avoids making spurious type distinctions.

Despite what I said on the phone, I think something like this is the
right solution.