[DGD]kernel cloning and inheriting

[Stephen Schmidt]

On Thu, 15 Feb 2001, Felix A. Croes wrote:
> In the kernel library, inheritables are not clonable, but I
> assume that you are talking about the general case.

That's right.
 
> If Ac did not exist, and A was a pure inheritable object, you could
> have upgraded A and B with the following sequence:
> 
>     destruct A
>     recompile B (will automatically compile A also)

If Ac did not exist, and you recompiled B without first
destructing A, then A would not be recompiled? I'm pretty
sure that's right.
 
> As it is, you can still do this, but of course the state of A will
> be lost thereby.

Although, the state of A will be lost even if Ac does not
exist. But if if Ac does exist, the changes in A due to
recompiling will not be reflected in Ac, because Ac loses
contact with A when A is destructed. Whereas if A could
be recompiled without first destructing it (if B did not
exist) then Ac would pick up the changes automagically.

The real problem is: If Ac and B both exist, you cannot
have changes to A be simultaneously be reflected in both
Ac and B. You can only have them reflected in B if you
first destruct A, and you can only have them reflected
in Ac if you do not destruct A.

Just out of pure curiosity, why is it not possible to
have changes in A reflected in both Ac and B? Is it
because A doesn't keep track of a list of all objects
that inherit it, so it doesn't know that when it updates
its own code, it has to update B also? Or is it that when
A is recompiled, you want B to keep the old behavior? Or
is there something deeper going on?

>  If A was a pure inheritable/clonable without its
> own state, you can do this without negative effects on A and B.

This seems to be based on an assumption that any object
which is inheritable does not use the state of its master
copy for anything important, so that when A is destructed
and its state lost, nothing bad happens. Certainly that
could be false. For instance, one could write a daemon that
tracked players (object A), use the master copy of A to track
all players, then have another daemon (B) inherit A and
track a subset of players (guild members, maybe). But that
would be Bad Design, IMHO. On the other hand, I bet I
could find muds out there that have parallel situations.
Bad Design is rampant in the world.

Good or bad, if that was done, then destructing A in order
to recompile B would have a negative effect when the state
of A was lost. Presumably one could code around this by
having A save its data to a file when destructed and
reloading from that file when reloaded.
 
Steve






List config page:  http://list.imaginary.com/mailman/listinfo/dgd