[DGD]upgrading old clones

balduin at uni-paderborn.de balduin at uni-paderborn.de
Wed Jul 7 11:01:49 CEST 1999


Just a question.
[...]
> I think sometimes a kfun to upgrade clones of an old issue may be useful.
> It need only work when there is a newer issue whose master object is
> not destructed.  The older issue may not have any inheriting dependents,
> but has at least one cloned dependent, of course, or it would not exist.
> 
>    object upgrade_clones(int issue_id)
> 

Is there a chance to retreive this issue_id from e.g one of the clones ?
If not, and I don't know a way, How would you plan to store this information 
needed to call the upgrade_clone function ?

[...]
> You could say, doing such a thing is stupid.  But imagine a wiz coming
> from another mud, where they are used to "destruct and compile".
> "Nooo!  What have you done?"  Also, it gives you more freedom working
> with the objects and makes for a more complete system for upgrading.
> If you keep inheritables and non-inheritables separate, as in the kernel
> library, clones of old issues are the only things you cannot upgrade.
> With a kfun like this, you could upgrade anything.

Unless there is a way to retreive the issue_id of the master through one
of the clones, you had to keep it ready in case of an emergency recover.
But this would imply that your lib has to support this emergency situation.

Instead, it's probably better to invest the work required to provide some 
"wizardly tools" for upgrade and forbid destructing of masters having 
clones. (But provide a tool to get rid of the clones if this really is what 
you wanted, otherwise there is compile_object)

-------------
Ah yes as i'm already in asking, suppose i have a deep inherit structure.
a <- b <- c <- *d
     b <- *e

(read "x <- y" as "x is inherited by y")
(read *z as "z has clones")

If I want to exchange a against a newer version and notice that only d and e 
have clones, there arise 2 questions.

1) Which masterobjects have to be exchanged ?
   a) a only
   b) a and b
   c) a, b, c ( and I must call compile_object in d,e ) (I fear c is correct)

2) If c) is correct, is there a way to walk through the tree to do the 
   upgrading automatically ?

3) If there is no straight forward way for 2) is there a way to provide the
   needed information by bookkeeping in e.g. clone_object ?


Ludger

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



More information about the DGD mailing list