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

Re: [MC] Multiple Inhertiance

--- "Seth I. Rich" wrote:
>>*  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?

I haven't decided exactly how this will be implemented yet.  I originally had
it as an in-DB property, but since properties are verbed, I'm not sure whether
it wouldn't be more appropriate as a server built-in property.

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

Slightly counter-intuitive, but it would simulate what would happen if the
parent
_wasn't_ there when the function was called, and it will provide a method for 
reordering the list.

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

True.  It will not be neccessary, just as $object_utils is not neccessary. 
However
it will make lives a lot simpler if it exists.  This document was not supposed
to
only talk about server modifications.

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

Oops.  The MOO that I work on is a heavily modified 1.7.8 server with 
__constructor and __destructor called on chparents as well as creates and
recycles.  Yes we will more or less grep the server code for references to
"parent", "children", and "sibling", and will modify each one to conform to
multiple-inheritance

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

Hmm.  For consistancy's sake, I suppose it could, but the parent -> child 
relationship doesn't change much, so this is not neccessary.  .parent may still
be a function under the name "parents(foo)"  I haven't fully decided yet.

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

They are required as "placeholders" to deal with cases like this:

foo.parents = {a,z}.  b.parents = {c}, c.parents = {d}, z.parents = {d}.  If
this
method were not in place, verbs on b and c would be bypassed if the repeats
were
not bubbled to the end.

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

Right, although the list is only re-generated when it is changed.  I suppose if
an
object with children is changed, it will be neccessary to regenerate the
child's
ranked_parent's as well.

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

I was thinking of a MOO with #1 as the ultimate ancestor for all of it's
objects. 
Indeed with verbed properties in place, a lot of E_VERBNFs will be generated if 
objects AREN'T descendants 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.

Ignored completely, unless searching for a command verb.  
Same as the current system.

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

It will be built-in to the server, I think.

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

It does.  What is the difference between these and regular verbs?

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

I don't see that.  If objects only have one parent, it will be just as
efficient
as the current system.  If objects have multiple parents, it will still be as
efficient, as objects are likely to be smaller, and have fewer verbs.

-manta
Home | Subject Index | Thread Index