Re: [MUD-Dev] MUD Design Fundamentals (Was: Looking for

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

>> I still think that changing the object-system (design) requires a wipe
>> unless you go through a lot of trouble to avoid it, if you use persistent
>> features.

>Adding/removing methods doesn't require any special consideration,

But that is true for most systems..

I get a feeling you are deliberatly misunderstanding what I say.
What I said about minor changes in the original post was something that
I knew were specific to some implementations.  What I say about major
changes is true for any system.  If you change the objectsystem then
there is going to be trouble, in any system, unless you have a
external representation that makes as few assumptions as possible about
the object system. The tradeoff is that you will only get the vital
attributes, and have to generate the less important ones.

Of course, you could internalize the simplistic external description
in any language, and derive/distribute the properties into the
objectsystem by cachingmechanisms or functions or duplication or whatever.
I just don't see the advantage.  Especially as I see efficiency as
important.  The only systems I consider for my own projects are
inherently dynamic, 50% of all attributes in the world would change at
least once a minute. I even care about utilizing the processor cache...
:-/ Boring, but neccessary as memory access is a serious bottleneck in
current architectures.  If I could do this in a slower than algol-type
language I would use available taskspecific systems like MudOS, right?

(Any commonlisp like language is ruled out anyway, because of their
ugliness :)

>> Anyway, for all practical purposes, I think C++ or other OO languages
>> decending from ALGOL/SIMULA was implied here.  I care about control and
>> efficiency, I believe other developers do the same.
>
>Efficiency is not necessarily the primary issue in MUD language design
>(i.e. it's usually not worth descending to stiff C++ OO model).

Eh, for what kind of system?  Efficiency isn't a primary issue in MUDs
that are mostly static, discrete and carry less than 200 users, but that
is not the direction the wind is blowing, is it? I'm even having trouble
with the efficiency of the freely availble C++ STL.  I certainly don't
want a persistence system that slows down my system considerably during
runtime!  I intend to do backups by forking off a duplicate process during
low load (not tried to do this yet) to avoid performance penalties.
(like the freezing in Meridian59)

Ola.