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

[Jon A. Lambert]

On  2 Sep 97 at 21:40, Ola Fosheim Grostad wrote:
> >explain what you mean by "splitting objects". As someone who isn't at
> 
> That's what changing the object-system was intended to mean.  To change,
> add and remove classes. To do major restructuring. 

I haven't heard of the term "splitting objects" either.  Nevertheless
I willingly accept ANY terminology as long as we are able to share 
conceptual understanding.  This sounds like a specific task of 
iterative design or development that I have done often.  I have no 
terminology for it though.

I might suggest that major restructuring can be avoided through 
intensive OO design work ahead of time.  And this depends on how 
much time you've invested into your mud's specifications.

I'm a big proponent of an 80/20 rule in effort in Analysis/Design as 
opposed to coding.  It takes a bit of patience to spec' a brainstorm 
rather than immediately code it.

> I wasn't talking
> about transforming instances, but in a pesistent system you would have
> to transform all instances of that class.  

Surely.  And this can be automated in a persistent system.  It may 
well be an expensive process.  But one must remember this is a 
development process.  I do not see this activity as occuring very 
often in a live and running mud.  You may well have significant  
concerns with a highly active user-base in a commercial environment.
This wouldn't be a major concern in my environment. 

> I'm not used to discuss OO
> outside my university, except for a whort while on a oo newsgroup which
> ended in some kind of flamewar between those that only viewed oo as a way
> of extending a programminglanguage, and those that viewed it as a
> way to build a conceptual model of the problem space (the part of the
> world that your program cares about).  

I wouldn't flame you over this. :)

> According to my OOA book
> "object system" is supposed to mean: The coming users perception of what
> the computersystem is used to admin, control or supervise.  This
> wouldn't make sense in a MUD system however.  When I talk OOP I take it
> to mean what concepts are present, and how they relate.  But I use it on
> a conceptual level, not on an instance level.

Hmm, it may be more productive to use OOP or OOPL when discussing 
implementation concerns and OO, OOA, or OOD when discussing 
conceptual concerns.  At least I think(?) many OOers on the list may 
concur with this.
 
> >Diku's where zone files are parsed and loaded. We mean something where
> >stuff can be written back to the disk representation when it is no longer
> >needed (e.g. the caching mechanisms have decided to punt it to make
> >space for something else).
> 
> OK. I figured quite a few LP's threw things back on disk, though not by
> caching. I'm probably wrong then.  Of course most of the stuff in LPs
> are generated and not stored, though objects get compiled and cloned
> when needed.

Sure.  I can't comment on what LPMuds are doing.  But many of us are 
doing "disk-based" systems and I think we all recognize the value of 
cheap memory.  I am using a configurable cache which can use all 
available memory if I desire.  I am also taking advantage of 
multi-threading especially in the area of network and disk I/O.  You 
mentioned in another post the ease of editting flat textual 
information.  I think the editting information in "popular" database 
formats can even be more convenient or productive.  That depends on 
your toolset to a good degree.
 
> >There is more to persistence than saving the state of the entire system?
> >Huh? Please elucidate.
> 
> You have to deal with realtime information, that changes between runs or
> which is invalid between runs, either by not saving, cleaning up before
> saving, cleaning up after saving or avoiding.  In a dedicated system, you
> may of course hide that stuff.

Transaction based recovery and restart.  Look to database theory for 
solutions here.

Jon A. Lambert