MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

[MC] Multiple Inhertiance



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.


Follow-Ups:

Home | Subject Index | Thread Index