# [MC] Multiple Inhertiance

Jefferson M. Dubrule (Jefferson.M.Dubrule@dartmouth.edu)
Wed, 10 Apr 1996 15:05:34 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    --- "Seth I. Rich" wrote:
    >>*  Each object will have a new property, foo.parents.  This will be a
    >>   list of objects.
    >Why is this a property as opposed to a builtin?  Is property access a more
    >efficient design?

    I haven't decided exactly how this will be implemented yet.  I originally had
    it as an in-DB property, but since properties are verbed, I'm not sure whether
    it wouldn't be more appropriate as a server built-in property.

    >add_parent(child, parent) changes the order of .parents if parent is already
    >a parent?  This seems arbitrary.

    Slightly counter-intuitive, but it would simulate what would happen if the
    parent
    _wasn't_ there when the function was called, and it will provide a method for
    reordering the list.

    >>*  For additional functionality $ancestry_utils will be created to handle
    minor
    >>   adjustments to family trees.  Because of the time it takes, most major
    >>   parentage changes should be done manually.

    >This has no place in server modifications.

    True.  It will not be neccessary, just as $object_utils is not neccessary.
    However
    it will make lives a lot simpler if it exists.  This document was not supposed
    to
    only talk about server modifications.

    >chparent() does not call any in-DB functions.

    >You may be thinking of create() and recycle(), which call the verbs you
    >mention (initialize and recycle, respectively).  You'd need to modify
    >create() such that create(foo) now creates an object such that its
    >.parents=={foo}.

    Oops.  The MOO that I work on is a heavily modified 1.7.8 server with
    __constructor and __destructor called on chparents as well as creates and
    recycles.  Yes we will more or less grep the server code for references to
    "parent", "children", and "sibling", and will modify each one to conform to
    multiple-inheritance

    >How will children() be modified?  Will it be changed to .children to
    >accompany the change from parent() to .parents?

    Hmm.  For consistancy's sake, I suppose it could, but the parent -> child
    relationship doesn't change much, so this is not neccessary.  .parent may still
    be a function under the name "parents(foo)"  I haven't fully decided yet.

    >>   This technique, however, produces repeats in the list.  Here's how they
    >>   will be dealt with: during the ranked_parent list compilation stage, if a
    >>   repeats is found, the first occurrence is removed from the list, and the
    >>   object ends up at the end of the list.

    >This second loop is unnecessary.  It would be simpler and quicker not to add
    >duplicates in the first place.

    They are required as "placeholders" to deal with cases like this:

    foo.parents = {a,z}.  b.parents = {c}, c.parents = {d}, z.parents = {d}.  If
    this
    method were not in place, verbs on b and c would be bypassed if the repeats
    were
    not bubbled to the end.

    >So the design here deals with verb calls by creating a list:
    >  {object, @object's parents, @object's parents' parents, ...} (without
    duplicates)
    >and checking that way?

    Right, although the list is only re-generated when it is changed.  I suppose if
    an
    object with children is changed, it will be neccessary to regenerate the
    child's
    ranked_parent's as well.

    >>   In the end, a list of objects beginning with the object, and ending with
    #1
    >>   will have been generated.

    >I assume you mean #-1 instead of #1.

    I was thinking of a MOO with #1 as the ultimate ancestor for all of it's
    objects.
    Indeed with verbed properties in place, a lot of E_VERBNFs will be generated if
    objects AREN'T descendants of #1

    >>*  Using this list, each object is scanned for "bar", until it is found.  If
    it
    >>   is NOT found, a E_VERBNF is raised.  Partial verbs (bar*) will be matched
    at
    >>   the same time, as they have the same priority as unambiguous ones.

    How are you going to handle !x verbs?  I assume that a !x verb will merely
    be ignored in this check, but you didn't specify.

    Ignored completely, unless searching for a command verb.
    Same as the current system.

    >*  This process, it seems might take a while, and given the number of verbs
    >   running, this might seem sub-optimal.  However, since the ranked_parents
    >   list only changes during add_parent and delete_parent, an in-server
    >   property can be added to every object: .ranked_parents.  This contains the
    >   list generated above.   Whenever a verb is called, this "cached" list will
    >   be used to find the appropriate object to call.

    Is this a server builtin, or are you suggesting that in-DB wrappers maintain
    this list?

    It will be built-in to the server, I think.

    >I notice that your design doesn't support multiple inheritance for command-
    >line verbs.  Why not?

    It does.  What is the difference between these and regular verbs?

    >I think that once again this is real bad design; the MOO server isn't designed
    >for multiple inheritance and this will be SLOW SLOW SLOW SLOW in production
    >use.

    I don't see that.  If objects only have one parent, it will be just as
    efficient
    as the current system.  If objects have multiple parents, it will still be as
    efficient, as objects are likely to be smaller, and have fewer verbs.

    -manta