[DGD] another aspect of persistence

[bart at wotf.org]

On Mon, 29 Sep 2008 17:20:33 -0700, Shentino wrote
> One thing I may suggest is...
> 
> Are the descs supposed to be fixed and global?

Sometimes descs are fixed, sometimes not. Global? usually not.
Fixed descs set from create() is something that is EXTREMELY common in
traditional lpmud code, and any codebase that is to support areas, objects or
any such thing written for a traditional lpmud is gonna cause one of 2 things:
1. It simply deals with the fact that this is being done
2. It forces you to change all such objects and forces a different way of
thinking onto your coders.

While I agree that 2. would be the better solution, when dealing with legacy
code, it is often simply not an option, so, like Chris and me (both supporting
lpmud alike legacy code) it really is option 1.

> 
> If so, then querying a constant in the master object would suffice.
> 
> Other than that, I would wonder why your descs would even NEED to be
> updated on a recompile.

Why would the desc change? You found a typo in it and want to fix it? (just to
name the easiest to imagine and most common reason, but there are really many
more such reasons).


> 
> Here's my favorite approach.
> 
> Don't call set_long at all.  Instead, leave "string long" equal to 
> nil or some other sentinel value, and "query_long" or whatnot could check
> for that and return a default value if the desc is blank.
> 
> Then, you could store a master default in the blueprint, or even as a
> raw quoted string embedded, such as this:
> 
> if (typeof(long) != T_NIL) {
>    return long;
> } else {
>    return "This is the default description that can be changed upon a
> recompile.";
> 
>    // or
> 
>    return blueprint->query_long();
> }

In a traditional lpmud, overriding query_long() or such is a way to get around
that yes. Doesn't fix having to change legacy code and teach a different, more
complicated way of doing this to your coders.

It also doesn't change that you have to deal with the exact same problem for
EVERYTHING that gets done on object initialisation. Being able to reinitialize
(ie, call create()) on upgrade solves a lot more then the longdesc issue.

Also, keep in mind that while using clones of a single standard room object
may be common on DGD, it is far from common on all other codebases, and also
on DGD, it is absolutely not a given fact. You may well end up with a lot of
custom coded rooms depending on design.

> 
> I would probably wish to do this even in an LPMUD type server, since
> having an identical string copied a bazillion times and sprawling 
> that through object land seems a bit redundant.

I think you are looking at a slightly different problem. Your solution for it
is quite nice tho. That said, I wouldn't end up a bazillion copies of the same
string anyway since virtually all rooms have unique (either generated or
handcrafted) descs.

> 
> Kotaka, btw, does this automatically via property inheritance.  If 
> you happen to use it later, all you need to do is tell PropertyD 
> that "long" is a "simply inherited" property that takes its value 
> from the first archetype if not defined locally.

In my case, for rooms this is generated from a 'room type' (simple variable in
rooms that can set a whole lot of defaults) and local details of the current
room, unless a (handcrafted) local override is provided.

As for upgraded(), in most objects on my mud it does a call to create() as it
does on Phantasmal.

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/