MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: [MC] Multiple Inhertiance

At 11:53 AM 4/10/96, Jefferson M. Dubrule wrote:
>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.

Multiple inheritance is not an easy issue in the least, and is one of the
more confusing aspects of languages (Such as C++) that do support it.  In
my opinion, it leads to more problems than it solves.  If you have a
situation where you need multiple inheritance, it could probably be
rewritten in a better way to only require single inheritance.

But anyhow...

>*  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 add_parent, why would it be moved to the end if it is already there?
You didn't really specify how order plays into the scheme.

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

If by 'done manually', you mean done by directly calling the builtin, then
I'd have to disagree.  The LambdaCore (And others, I'd bet) is set up such
that the typical programmer rarely has to call builtins.  Verbs are
provided to do most of this work.

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

This doesn't make sense to me.  First, delete_parent should be able to
delete *any* parent, not just the first one.  Second, why would deleting
the first parent leave an object with no parents?  Couldn't there be other
parents left?

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

What if you find more than one object with a matching verb?  You didn't
handle this (common) instance.

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

You'd also have to update this property on a recycle() or a renumber().
And don't forget that you'd have to recurse down the list of children and
do it for each of them.


You haven't handled properties, which could be difficult to work with in a
multiple inheritance situation.  If an object has multiple parents, which
properties do you plan on using if there's overlap?  These kind of issues
are difficult.

Please don't think I'm trying to attack your idea and plan specifically; I
just believe that multiple inheritance is something better left out of MOO.

Matt Pauker
mpauker@peganet.com
Follow-Ups:
Home | Subject Index | Thread Index