MOO-cows Mailing List Archive


inMOO Multiple Inheritance

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

          Calculates a list of all the parents of the object.

          OO verb call.  Does the chparenting and actual verb call.

          fetches the value of a multiply-inherited possibly persistent 

          Returns 1 if the property is accessible on the object for MI 

          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.   

          Returns first object in {this,@all_parents} on which the 
          verb is defined.

          Restores the persistent properties of the current object.

          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


Home | Subject Index | Thread Index