# [MC] Multiple Inhertiance

Jefferson M. Dubrule (Jefferson.M.Dubrule@dartmouth.edu)
Wed, 10 Apr 1996 14:41:37 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

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