Subject: Multiple Inheritance

From: [email-masked] (Chad Wilson)
Date: Sat, 27 Mar 1993 13:16:24 -0800

What is require to change LambdaMOO server code v1.7.0 from linear to
multiple inheritance?

---

From: [email-masked] (Mike 'What Day is it?' Wilson)
Date: Sat, 27 Mar 1993 15:31:50 -0800

Not sure about what it takes ... If you know, I might be willing to try it,
depending on what is involved.
Mike

---

From: [email-masked] (John Rogers)
Date: Sat, 27 Mar 1993 18:36:16 -0800

> depending on what is involved.

I suspect it would entail quite a modification!  I am willing to bet that it
constitutes a version 2.x of MOO!  ^_^  Ok, since MI (Multiple Inheritance
for short) is a very much wanted item on MOO, let us take a look at how MOO
might have to be changed to support MI.

[Remark: There is *no* agreement on how MI should be done.  Interested
         readers may take a look at the chapter on MI in Timothy Budd's
         "An Introduction to Object-Oriented Programming", as well as look
         at how C++ and CLOS implement MI.  The discussion below on my
         "implementation" of MI is admittedly vague...so please think
         carefully before flaming me ^_^]

1.) First of all, we will have to change the ..parent (I use double dots to
    denote internal properties, a bit like the UNIX's style of hiding files
    using the leading dot ^_^) format, which merely contains an object
    number, to ..parents, which contains a LIST of object numbers.  Also, we
    would change the definition of "no ancestors":  on ..parent, it is
    indicated by #-1 ($nothing).  on ..parents, it would be denoted by {}.
2.) Change various primitive routines to reflect that change.  The biggest
    change would certainly be in chparent(), with the attending headache of
    preserving the data (I am not 100% sure exactly how it would be done!)
3.) The calling machinery would definitely be overhauled.  Here is one of
    the more contentious points of the implementation of MI.  My approach
    would be to treat ..parents as if it is literally ordered in sequence
    for method (aka 'verb' for MOO folks) search.  Example:  Let ..parents
    contain { #5, #6, #7 }.  Then a search for, say, "tease", would begin
    on #5, and recursively scan its parents.  Should it fail here, #6 is
    next attempted.  #7 would be searched in case it has no luck with #6.
4.) Sometimes one may need to invoke a particular verb on the specified
    parent.  That means the pass() would have to be enhanced/expanded to
    support that.  That in turn raise an issue of the relationship of
    ..parents to pass().
5.) Lastly, but not the final (in fact it is just a beginning!) one would
    have to deal with all those references to properties.  The book I
    mentioned above gave a short, but good discussion of these issues.

I only outlined the changes that would be needed on the MOO...I am sure I
may have not thought of other (obvious) ones.  Have fun pondering the
MI-ization of MOO!

------------------------------------------------------------------------------
         ///            | The Blue Wizard Of Dragon Order (John Rogers)
        ///  Only Amiga | [email-masked]
  \\\  ///  gives you a | (Don't toucha my wand or I will breaka ya!)
   \\\/// creative edge |     #include <std.disclaimers>
    \XX/                |     cat flames >/dev/null 
------------------------------------------------------------------------------

---

From: Larry Masinter <[email-masked]>
Date: Mon, 29 Mar 1993 15:02:41 -0800

Having lived through this debate in the CLOS wars (Common Lisp Object
System), I'll say that it no matter what MI system you pick, there's
some case where you'd wish you had another one.

Given that, I'd vote for depth-first.