[MUD-Dev] Multiple Inheritance (was: Object Models)

[Bruce]

J C Lawrence wrote:
> 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.

Just as a note, there is at least one other approach, used by TOM
(http://www.gerbil.org/tom/).  Quoting from the TOM Tome:

---begin---
Semantics

Suppose the class D has both B and C as a superclass.

implementation class D: B, C
end;

implementation instance D
end;

What effect does this inheritance of two classes have?

 * Any state defined for instances of B or C is also present
   in instances of D. There is no sharing of slots based on
   the name of instance variables as in CLOS. Thus, every
   instance variable i consuming space in an instance of B or
   C, also consumes space in an instance of D.
 * Every method defined for B is also defined for D. Obviously,
   every method defined for C is also defined for D.
 * If both B and C define the same method foo, a method clash
   is said to have occured, and D should provide its own
   implementation of that method. This is not mandatory;
   it is not checked by the compiler; it is optionally checked
   by the resolver. If a method clash is not resolved, a
   program-condition is raised when the method is invoked at
   run time.

A class with instances that carry state (i.e., instance
variables) must be a subclass of the State class. If both B and C
maintain state, they must both inherit from State, which brings
up the issues involving repeated inheritance. Actually, these
issues are mild in TOM when compared to the same issues in
languages like C++ or Eiffel. To sum it up: repeated inheritance
is shared inheritance.

 * With respect to instance variables, things remain the same:
   every instance variable declared in a superclass gets its spot
   in the subclass. Thus, D only has one isa instance variable
   (inherited from State), even though it `is inherited twice'.
 * If a method foo is defined by State, unharmed by B, and
   redefined by C, it is the redefinition of C that is applicable
   to D. The implementation by State that `is visible' through
the
   inheritance of B is nulled by it being overriden in the
inheritance
   path through C.

----end----

For me, this works rather well, as it is nice to make sure that
classes are resolved and that the programmer is explicitly aware
of what paths are being executed at runtime.

I'd like to see compiler support for warning about this
happening, and maybe I'll add it, although with the way that TOM
can handle dynamic runtime and linktime modification of classes
and loading of code, this error can pop up without a warning. 
Just another big reason why having tests and a good engineering
focused environment is important to manage and control change. :)

 - Bruce
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev