# [MC] Multiple Inhertiance

Jefferson M. Dubrule (Jefferson.M.Dubrule@dartmouth.edu)
Wed, 10 Apr 1996 11:53:11 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.

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

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

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

    *  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)"

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

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

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

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

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

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

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

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