[MUD-Dev] Object Models

[J C Lawrence]

On Wed, 15 Nov 2000 21:41:12 -0500 
Ben  <bjchambers at phoenixdsl.com> wrote:

>     Okay, I am aware that a) this may have been discussed prior,
> and b) it may go a little to far into technicalities, however I
> feel that this is a very controversial subject in the minds of
> many programmers, as it has a major impact in the way the MUD is
> engineered.

True.

>     Now what I am wondering is how you all handle the objects in
> your MUD.  The two camps that I am aware of is the strict old
> style method of definining every single object.  The alternative
> camp is that which feels that you should have multiple types of
> objects, and then have each object dynamically inheriting the
> properties that pertain to it.  The problem I have run into is a)
> how do you handle the dynamic inheritance b) how do you error
> check with dynamic inheritance and c) how do you save/load dynamic
> inheritances.  I realize that dynamic inheritance may not even be
> possible, but from what I have heard that seems to be what you all
> are talking about.  Basically I want to have an object type named
> object, everything else derives from object, but has additional
> properties.  For example I have an object that is both a key and a
> monster.  Instead of having an object type key_monster, I would
> like to have an object of type object that has inherited the
> properties of a key and of a monster.

>     How do you handle these things?

What you are talking about is called "multiple inheritance".  It is
not an entirely trivial topic, and in fact has a number of very ugly
aspects.  Its worth spending some time reading up about multiple
inheritance and single inheritance via your favourite search engine.
If you want too look into this from a MUD server code perspective
I'd advise starting out by looking at COOLMUD and then perhaps ColdX
(there are a couple ColdX servers out there already online that
allow "test play").  Both implement rather well documented multiple
inheritance schemes.  I'd also suggest looking into other
comparitive techniques such as Java's concepts of "interfaces" (tres
neat).

Now, as far as how you handle it at run time?  Essentially you end
up building a graph of the methods accessable to a given object.
You start with the object you are interested in, which has a certain
set of methods defined on it, and then start working back thru its
various parents (what it inhereits from).  As you do this traversal,
build a graph of what methods are defined where and by what, that
the current object inherits.

Consider the following:

  ObjectA: defines method X()
  ObjectB: defined method X()
  ObjectC: inherits from ObjectA and ObjectB

What gets called when I do D.X()?

The typical solutions are either depth first or breadth first
traversals.  Each is a trade-off, and each will get you
unexpected/unwelcome results in certain cases.  

How to implement this?

  ObjectX.methodY() is called.

  Look at methods defined on ObjectX for methodY().
    If found, call it.
    If not found, find first parent of ObjectX
      Look at methods defined on ObjectX's parent for methodY().
        If found, call it.
        If not found, find first parent of current object.
        ...etc.
   If no parent on current object, return to previous object and
     take next parent.
     ...etc.

Warning: Multiple inheritance tends to get ugly, quickly,
especically when used by occassional programmers.  To build a
multiple inheritance tree that makes sense requires some skill and
considerable forethought.

--
J C Lawrence                                       claw at kanga.nu
---------(*)                        : http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev