[MUD-Dev] Components and Inheritence

[John Buehler]

Jon Lambert writes:

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

Agreed.  I believe I've mentioned that inheritance permits a subset of the
designs possible by using components.  Just as components permit a subset of
the designs possible using a turing-complete language.  Interestingly, we
were wondering how many components of a non-trivial nature would be required
to build just about all possible applications.  A 'turing-complete' set of
components, if you will.  The *trivial* set of components would be
components that implement individual machine instructions.  But that would
be a shade on the inefficient side.

> 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 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 consider component constructions to be a hierarchical mechanism that never
stops.  You spent the time to create some functionality, so you popped it
into some intelligently-constructed components.  Great for me!  Now I can
grab those components and reuse them.  They are nicely-encapsulated
functionality.  If you go ahead and code a traditional 'application' around
some existing components, then all I can do is reuse the component portions
and cut/paste the rest and go back to the traditional morass of trying to
reuse code.  The end result: nobody bothers with components and components
become like the ActiveX toolkit.  One more step forward, but everything
built on top of that toolkit is not reuseable.

As I said, you may believe that there are practical techniques for getting
reuse, quality control, etc, for methods, inheritance-based class
constructions and the like.  I haven't seen them, and what I HAVE seen of
components tends to suggest that such things are too loose to build
arbitrarily large applications.

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

JB


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