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

[Miroslav Silovic]

> 
> >cold or Smalltalk) do NOT require such an active effort.  In genral the
> >difference is in tehcnase of cold or Smalltalk the persistance is built
> >into the system, in the case of a C++ persistance library it is an add on.
> 
> Well, I agree, that the ideal situation would be to have persitance as a
> part of the language design specs.  I still don't see how you can ignore
> realtime information, UNLESS the language is dedicated to the task at hand.
> 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.

Not true, actually. CLOS allows you to change class specification or even
inheritance information in the running system without loosing information
(apart from the slots that were removed from reparented objects).
(CLOS is Common LISP Object System). 

I can say how Cold does it. Several things can change: You can change
property specifications on an object, method specs, or parenting.
For properties, adding doesn't require any special consideration as
internal object representation doesn't store the properties that
weren't set for that instance of the object, and deleting a property
requires descendant traversal for cleanup (this is expensive operation).
Adding/removing methods doesn't require any special consideration,
as method lookups are dynamic (and cached for speed) - basically
cache is timestamped, and timestamp is incremented in object
creation/deletion/reparenting and method changes.
Finally, reparenting is VERY costly, as it requires heavy traversal
and reinitialization (Cold is designed to keep the database robust
under abuse). Yes, this actually means that reparenting a player to
something bizarre (like a realm) will properly update player database
object, realm registries and similar external objects. Of course,
some of these will spin your disk for a long time (but then, you
won't go changing inheritance just every day).

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

> My main point was that persistance isn't neccessarily going to save your
> butt, although it "sounds like magic".  I would at least go for secondary
> backup functions that store information in an easily parsable format for
> saving and loading the most essential information.  If not, you are
> probably stuck with your initial design, or have to accept more clean
> wipes than you like.

OO store can be VERY robust. Most of those that aren't simply rollback
to the last backup if something goes horribly wrong. However, persistant
systems I worked with have LOTS of protection against DB destruction,
even if you start shooting at objects.

	Miro