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

Re: [MC] Multiple Inhertiance

--- Matt Pauker wrote:
>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.

Ok.  If object foo has parents {A, B, C}, A will be checked first, then B then
C.

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

I mean really major changes like reordering the parents parents of $room or 
$player.

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

>First, delete_parent should be able to delete *any* parent, not just the 
>first one.

It can.  Just call delete_parent(parent) and parent will disappear from 
.parents.  The point was ALL parents can be deleted, not just down to one.

>Second, why would deleting the first parent leave an object with no parents?

Well, if it only had one parent at the time. . . 

>Couldn't there be other parents left?

Yes.

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

Since only one object at a time is considered, there will be no ambiguity
that isn't in the server right now.

>You'd also have to update .ranked_parents 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.

True.

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

I think it would be very cool to have.  Consider a MOO with, instead of huge
objects, a whole pile of feather-weight objects.  To make an object do what
you want it to, just add_parent the appropriate objects.  So, if you wanted
a locked combination safe, make it a child of "the generic box", "the 
generic lock", and "the generic combination checker" and put a few token 
verbs to attach the .locked status to whether or not the box can be opened, 
and the combination checker to the :unlock verb, inherited from the lock.

-manta
Home | Subject Index | Thread Index