MOO-cows Mailing List Archive
[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
* 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
* Method of add_parent(child, parent) cycle checking
* scan through parent.ranked_parents to find child. If it is present,
Subject Index |