[MUD-Dev] Components and Inheritence
tychomud at ix.netcom.com
Fri Dec 1 02:55:44 New Zealand Daylight Time 2000
Joe Andrieu wrote:
> John Buehler wrote:
> > But in an inheritance system, the parent and child classes cooperate in
> > providing behavior. Parent classes can provide utility methods that child
> > classes can employ, child classes can ignore the parent implementation, or
> > incorporate the parent implementation into their own behavior.
> It seems like the value of components is that it forces you to be
> strict and define your relationships clearly and cleanly, while
> inheritance allows a programmer to just run with the inheritance and
> do whatever, dealing with conflicts when they are a problem. Or put
> differently, components allows the diligent programmer to write tight,
> clean code, while inheritance allows a looser mechanism for building
> out the codebase.
I don't believe the use of a component approach is mutually exclusive
with inheritence. My view of components is that of black box inheritence.
A component is a application relevant view of an inheritence tree
(or a Composite). One can design a mud language that has multiple
levels of functionality...it's glue, a fully functional OOPL that allows
white box inheritence, and a component building language.
I believe components are best used in conjunction with simple glue by
non-programmers (tool-users). These are the people you don't want
"hanging themselves", not the mud library programmers (the tool-builders).
Components and glue are the ideal "level" for your builders, creative
writers, and tinkerers which are players who have the capability in-game
to build and assemble things.
So I've decided on a multi-level approach to designing my MPL. My mud
language Aphrodite supports an Object Model similar to that of C++.
Apollo is basically an interface definition language that is used to build
components. This all all brought together in Artemis a visual programming,
creative writing and building interface. A component is very similar to
an ActiveX module. It is exposes properties that may be modified at runtime
via glue code or at design time.
--* Jon A. Lambert - TychoMUD Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev