[DGD] another aspect of persistence

[Shentino]

One thing I may suggest is...

Are the descs supposed to be fixed and global?

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.

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();
}

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.

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.

On Mon, Sep 29, 2008 at 2:59 PM, Noah Gibbs <noah_gibbs at yahoo.com> wrote:
>  One option is to have an upgraded() function with that kind of thing, and call to it from create().  Phantasmal does this in most of its codebase.
>
>  For data like descriptions, integers, et cetera, you can also have some kind of data storage that's settable with an API call, but that's a pretty significant architectural change from most LPMUDs.
>
> --- On Mon, 9/29/08, chris . <psych_mayo at hotmail.com> wrote:
>
>> From: chris . <psych_mayo at hotmail.com>
>> Subject: [DGD] another aspect of persistence
>> To: dgd at dworkin.nl
>> Date: Monday, September 29, 2008, 1:59 PM
>> I've come across another aspect of persistence i need to
>> consider in my overall design.  I made up a function to
>> update libs and objects.  One of the first things i noticed,
>> since I was using set_long(x) in create() for an objects
>> long desc, than upgrading does nothing to reflect a change
>> to the description (since the object was already created).
>> To get around this, I've thought about calling an
>> upgrade function in each object getting upgraded which works
>> similar to create (for values which don't change over
>> time).  In addition i have figured on using something like
>> set_long(long() )...or else just have query_long return
>> long().
>> I've shot down several other ideas i came up with to
>> solve this...in fact every solution so far seems to have
>> some drawbacks or in the least quite a bit of extra work.
>> Im going to hit the drawing board soon, and try to come up
>> with a better option than the one i just mentioned.  Im
>> particularly concerned that my approach is a real OLC-based
>> design killer (requiring values to ultimately be determined
>> by a function instead of a variable).
>> I wondered how else members of this community dealt with
>> this.
>> Thanks all,
>> -chris
>> _________________________________________________________________
>> Stay up to date on your PC, the Web, and your mobile phone
>> with Windows Live.
>> http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/
>> ___________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>
>
>
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>