[MUD-Dev] Components and Inheritence

[Jon Lambert]

John Buehler wrote:
> Jon Lambert writes:

>> 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.

> This is a fundamental point, and one that I disagree with pretty
> vehemently.  It states that it's important to have high quality
> code at the core, but that then the rigorous techniques can be set
> aside.  But that just means that the crashes and odd behaviors
> migrade to the glue code.

I believe the level of rigor in the glue code should be sufficient
enough to not allow the system to never crash, but not sufficient
enough to prevent the programmers at the component/glue level to
write and execute erroneous code.  Let me explain it another way...

Aphrodite is a language that runs embedded in a server environment
and is runtime dynamic.  It can and will encounter errors and
exceptions.  Under no circumstances is it acceptable that those
errors and exceptions crash the environment (the server).  They can
only crash the particular thread of execution in which they occur.
And since all events to initiate a given thread of execution are
issued asynchrounously, there are no dependencies on the failure or
success of any event to execute correctly.

Now that level of rigor (or stability) is fairly easily
achieved. *grin* Specifically the server stays up and the game runs
at all costs.  Of course it is certainly possible for a programmer
with a high level of security to break parts of the game, or even
break enough parts, or the right parts to render the game
environment useless.  Objects cannot be modified unless the caller
has sufficient authority to request a change AND then only through
requesting the object to modify itself.  In other words this is a
pure event system, with objects checking the callers security.

So what is available to the particular programmer who uses the
glue/component level are only those components they are authorized
to use.  The integrity of the components that are exposed for public
use is of much higher quality and rigorous testing (from an software
engineer view) than those being assembled with glue by your
builders, writers and tinkerers.  So by virtue of security, the
least amount of damage can be done at that level and the highest
concentration of errors is also expected to occur at that level.

> I equate the component technique with an intensive inspection of
> packaged functionality.  I equate traditional methods with a
> straight introduction of machine instructions to the execution
> space.  Perhaps you are thinking of other techniques that can be
> applied to glue code, but the point is that you believe that
> there's no need to pursue components as a complete building
> material for an application.  That simply makes no sense to me.

I do believe components are very useful.  I do not believe they can
currently be pursued as a complete bottom up solution.  This is a
practical matter.  I believe that there may be a time in the future
where they may well be.  I do not know of any existing
tools/languages/frameworks currently available that allow
application building using components without glue.

However it has occurred to me that many of the object models that
are haven't been fully discussed (TOM, MOO and ColdC) may really be
closer in spirit to Component technology than they are to the OO
model.  For instance, many of these languages have been used to
build libraries of objects that are definitely blackboxes and
respond in a predictable manner (ala contract).

>> 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.

> I know this is asking a lot, but I'd be very interested to know
> what percentage of your code goes into components versus glue
> code.  Best of luck with the project.

Currently I have only 3 working components.  I expect to have
hundreds more.  But the reason I selected these particular
sub-applications to build first as components was because of the
huge amount of effort required to build them.  So 99% of the code
resides in the component vs. the glue to use them.  These are the
three most complex components I ever expect to build.  So I would
expect that ratio to drop quite a bit to perhaps 75% or so.  One of
these components is composed of merely validation routines that are
stubs written in Aphrodite to a native C library which exists
outside and independent of the server system.  That's because it's
an optional component that I myself must license separately.  I did
not want to make it an intrinsic part of the server because it might
preclude me distributing it one day.  Although it is illustrative of
how powerful components are in terms of coupling.  It's presence or
lack of presence does not require any changes in Mud Library code.

--
--* 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
https://www.kanga.nu/lists/listinfo/mud-dev