# [MC] Multiple Inhertiance

"Seth I. Rich" (sir@po.cwru.edu)
Wed, 10 Apr 1996 12:54:57 PDT

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

    >In the same vein as the Verbed properties text, I am submitting for comment
    >this proposal for adding multiple inheritance to the MOO.  For property access,
    >the Verbed Properties system, submitted earlier, that is almost complete now,
    >will be used.  As before, when the patch is complete, and seems stable, it will
    >be made publically available.

    >*  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?

    >*  add_parent(object foo, object fred) and delete_parent(object foo, object
    >   fred) will be added.  add_parent adds fred to the end of foo.parents; if
    >   fred is already there, it is moved to the end.  delete_parent removes fred
    >   from foo.parents; if fred is not there, E_INVARG is raised.

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

    >*  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.

    >*  add_parent will check for cycles in the parental heirarchy, and will raise
    >   E_RECMOVE when a cycle would be generated.

    Good.

    >*  delete_parent will even delete the first parent, leaving an object with no
    >   parents.  This will be the same as the current "chparent(foo, #-1)"

    Good.

    >*  chparent() is obsolete and will be removed and its functions (initialise &
    >   recycle calling, etc.) will be distributed among add_parent and
    >   delete_parent.

    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}.

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

    >*  When a verb is called (foo:bar), a list of objects is generated.  This list
    >   will roughly be the contents of a breadth-first traversal of the parentage
    >   tree, generated as follows:
    >
    >   First, add the object foo with.  Then add each of the objects in
    >   foo.parents with now, take each of their parents, and add them to the list.
    >   Continue until all have hit #-1.
    >
    >   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.

    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?

    >   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.

    >*  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.

    >*  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?  Note that this list also changes during recycle() and renumber()
    calls; you need to support those as well.

    >*  parent(foo) is now obsolete and will be replaced by foo.parents.

    Ok... See above regarding children()

    >*  ranked_parents(foo) will be added for informational purposes (similar to
    >   decompile())

    Why have both a builtin and a property to return the same value?  Unnecessary
    waste.

    >*  Method of add_parent(child, parent) cycle checking
    >   *  scan through parent.ranked_parents to find child.  If it is present,
    >      raise E_RECMOVE.

    Ok...

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

    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.

    Seth / Blackbriar
    ----------------------------------------------------------------------
    Seth I. Rich - sir@po.cwru.edu
                                     There is nothing more precious than
    Rabbits on walls, no problem.    a tear of true repentance.