[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Bruce wrote:

> There's also the whole argument in favor of components and those
> types of systems which were heavily promoted by John Buehler some
> months ago, and with good reason.

I view "components" as something invented for business applications
which tend to deal with rather stable domains or no hard realtime
requirements or serious interdependency performance issues AND which
have to deal with a bunch of existing legacy systems and lots of bloat
and incompetent programmers...

But for state-of-the-art MUDs... Why put up a concrete wall between
your modules?  This is not good for a system that is supposed to
evolve.  By advocating components one just says that one has given up
finding a good flexible design AND that you know exactly where
flexibility will be needed.  In a virtual world however, dependencies
tend to be related to groupings like geographical areas and you seldom
can say that there will never exist dependencies between different
types (classes) in the future! On the contrary, to have depth (which
most MUDs don't have) you want LOTS of relations between those types
if you can handle it.

IMHO layers, modularity, invariants, separation of responsibilities,
refactoring and all that is good, but components-as-advocated
(specification based, stable, 3rd party replaceable, no need to
recompile etc) are not!

Obviously if you are going to implement a MUD design of the 1990's
then you can get away with the performance penalty and the
inflexibility which comes with components... However, you can achieve
the same thing without the performance issues by being disciplined
about which classes you depend on (like which header files you
include, which is easy to verify).

(This is not to say that you cannot implement certain modules as
components with no penalty, but the core that constitutes the MUD
cannot be built with components without penalty...)

--
Ola  -  http://www.notam.uio.no/~olagr/

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