# inMOO Multiple Inheritance

dave@ipac.caltech.edu (dave@ipac.caltech.edu)
Wed, 10 Apr 1996 16:50:12 PDT

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

    There have been a number of experiments making an in-DB multiple inheritance
    scheme work.  The ones I'm most aware of are Andy Wilson's and the different
    one I did, both about 2 years ago on LambdaMOO (before lagdeath).  You may
    want to experiment with various in-db schemes, which are fast to prototype
    compared to server hacking, before committing to particular server
    modifications.  For this kind of work, the performance hit is not big
    compared to the much harder development environment you have to deal with
    when modifying the server.  When you think you have it right, transfer it
    to the server.

    Anyways, the MI thingie I made is #913 on Lambda, here is its "man" page:

    Experimental Mulitple Inheritance Base Object
    =============================================

    This object provides the base functionality for a class of objects
    that implement an in-moo multiple inheritance scheme.  The idea is
    simple.  Since there is no true multiple inheritance in moo we just
    change the parent on the fly to the appropriate object and then call
    the appropriate verb.  Properties are handled by defining a new
    property state, which may be either volatile or persistent.
    Persistent properties remain defined (and keep their values) across
    chparenting.  Volatile properties do not and take on the value of the
    current parent.

    Builder's interface
    ===================

    @addparent <mi-object> to <this>
              Adds the object <mi-object>, which must be a descendent of
              <this>.root to the parents of <this>.  This should be done from
              the bottom to the top of the hierarchy.  @addparenting again
              will update the all_parents list if you get the order wrong.

    @rmparent <mi-object> from <this>
              Removes <mi-object> as a parent of <this>.

    @persistent <prop-name> in <this>
              Flags the property <prop-name> as persistent, ie it retains
              its definition across chparenting verb calls.

    @volatile <prop-name> in <this>
              Unflags the property <prop-name> as persistent.  It will no
              longer retain its definition (or even existence) across
              chparenting verb calls.

    @pprops <this>
              Shows the list of persistent properties of <this>.

    @ppval <prop-name> in <this>
              Shows the value of persistent property <prop-name>

    Programmer's interface
    ======================

    all_parents()
              Calculates a list of all the parents of the object.

    call_verb(<verb-name>,<arg-list>)
              OO verb call.  Does the chparenting and actual verb call.

    get_prop(<prop-name>)
              fetches the value of a multiply-inherited possibly persistent
              property.

    has_property(<prop-name>
              Returns 1 if the property is accessible on the object for MI
              purposes.

    object_matching_property(<prop-name>)
              Returns the object defining <prop-name> according to MI
              rules:  this if property is explicitly defined or is persistent,
              otherwise first object in all_parents.

    object_matching_verb(<verb-name>)
              Returns first object in {this,@all_parents} on which the
              verb is defined.

    restore_persistent_properties()
              Restores the persistent properties of the current object.

    save_persistent_properties()
              Saves the persistent proeprties of the current object.

    ---

    On AstroVR, we're trying out the feature-object for objects idea.
    This actually gives a big performance advantage compared to the above
    MI scheme (about 20 ticks per verb lookup compared to about 200).  The
    basic idea is to plug in an adaptor to an object so it can then
    support these add-ons.  The adaptor has all the verb calling
    mechanisms and installation hooks.  Then use lightweight instances of
    FO-like objects that plug into the other side of the adaptor to
    provide functionality (and hold data).  There are a bunch of
    interesting complications in actually making this work, but they are
    solvable.  It seems to work amazingly well.

    Cheers, DVB