[DGD] A few questions

[Felix A. Croes]

"Jesse Garrison" <jgarriso at gmail.com> wrote:

>[...]
> The issue I run into then is that every object right down to the
> clones is going to have a copy of this variable. That seems slightly
> wasteful, but I don't know if it will make a big difference in the
> long run since it should never be initialized for them. I've looked,
> but I haven't found a way to make a variable ONLY appear in the
> current object, rather than appearing in all of its children or
> clones.
>
> So what is the proper way of storing these lists? I think I read
> somewhere to use LWOs and just put an object pointer in every object
> that could be used to point to such a list. Is this the most effective
> solution?

When using the kernel library, you cannot store data in inheritables
at all, since they are forced to be pure classes which cannot be
initialized.

The kernel library keeps track of objects (per owner) with a double-
linked list.  Alternatively, you could store arrays of objects in
some other place than the inherited object.


> 2) On the Phantasmal site in the Persistence section there is a quote
> from Par Winzell that says "In a persistent world, rather than write a
> lot of startup code, you tend to write behavior code, and configure
> objects." Now this is probably just my MudOS background talking, but
> if all of your objects are virtual where do you put this behavior
> code?

If they're all virtual, by necessity in the source code for the object
they're cloned from.  

To answer the remainder of your question, imagine you're making some
chair in a room.  In a persistent mud, this chair will be around
forever (or until it is explicitly destructed), but you may occasionally
want to modify the behaviour of this chair (or of all chairs).  Since
it will only be initialized once, there is no point in keeping the
initialization code around once that has happened.  After being
created, the chair could be recompiled without initialization code
and it would still work perfectly.

However, some chair alternations will require a modification of
the object's internal datastructures.  The easiest way to do that
is to add some temporary "patch" code which performs the required
modification.  Once this has taken place, there is no reason to
keep that patch code around, either.

At this point one may come to the realization that modifying an
object's datastructures is rather a lot like initializing it in
the first place, and that some generalized way of configuring an
object -- that is, setting up or altering its internal
datastructures -- may be very useful...

Regards,
Dworkin