[DGD] preserving vars after lib recompile

[bart at wotf.org]

On Wed, 17 Sep 2008 16:03:51 +0200, Petter Nyström wrote
> The below is all from my quite possibly fogged view of how DGD works.
> 
> On Wed, Sep 17, 2008 at 2:46 PM, chris . <psych_mayo at hotmail.com> wrote:
> 
> > I thought that if a library had data in it, and an object inherits it,
that when i change the lib, the object will have to be destructed and cloned
fresh.
> 
> No, it doesn't. If you want to recompile the object to use the 
> changed lib, what you need to do is to first destruct the lib and 
> then recompile the object. Recompiling the object will automatically 
> compile the inherited files needed.

Provided you have the proper filesystem permissions to compile them of course :)

But indeed, destructing the 'in between' libraries yourself is not needed, the
driver will call the driver object for those, which will do the actual
destruction. In other words, you only have to worry about the end nodes of the
graph (the library you changed on one end, all the objects that (in)directly
inherit it on the other end)

klib matters a bit for the implementation, but not at all for how this works
in concept,

> Unless there is a change of 
> variable declarations in the lib, no data will be lost in the 
> recompiled object. All data that belonged to the lib object is 
> however lost when you destruct it - so don't keep data in library objects.

At the risk of complicating the whole story.. there is actually a use for
storing data on libraries when the data is specific for that version (or issue
as DGD calls it internally) of that library.

One alternative to the 'traditional' objectd based upgrade methods that I am
investigating makes use of this as follows:

When an object inherits a library, this is registered on the 'master' for that
library.

Just before the library gets destructed, the list of objects depending on it
is posted to a daemon that maintains an upgrade queue. This daemon can then be
called to do the recompiling of all the depending objects.

This basicly eliminates the need for an object daemon and for keeping track of
all different issues of a lib that might exist, for as far as upgrading is
concerned. Of course you may still want to use an object daemon for other
reasons, but if you can do without, it will save one object with a potentially
huge dataset (which tends to be a bit of a pain for swapping)

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