[DGD]Object Upgrading Scenario

[balduin at uni-paderborn.de]

> Back to the original problem then.  The proposed scenario is
> 
>      A -i-> B -i-> C -c-> D
>      A -i-> B -i-> C -i-> E -c-> F
> 
> The problem here is when D clones C.  The solution is an adaptation of a
> solution I 'thought' I'd worked out a few days ago, until I realised my
> memory of how it all worked was a little backwards ;)  Anyway, for ease
> of explanation, we'll call C the primary master, a new object, CX,
> called the secondary master and D will be the clone
> 
Just to make sure I get your approach correctly, you extend the hierarchy
by changing
>      A -i-> B -i-> C -c-> D
>      A -i-> B -i-> C -i-> E -c-> F
to 
>      A -i-> B -i-> C -i-> Cx -c-> D
>      A -i-> B -i-> C -i-> E -c-> F

where obviously C is no longer in mixed use (both cloned and inherited). 

> Now, when a call is made to clone an object, the clone_object can create
> the secondary master by creating a file that inherits the primary
> master, and nothing else.  The name of this can be determined by some
> algorithm so they can all be hidden from the user, thus making it all
> transparent.  The clone D, can then be made of the secondary master,
> leaving the primary master free to be inherited.
> 
> This will also fit right into Jason's original ideas on how to deal with
> upgrading inherited objects.  Obviously, you would not hide these files
> from the internal processes dealing with it all ;)

It is easy to see, that you can avoid the situation of mixed use by this
approach. Given the structure it is also easy to see what has to be done if 
I want to upgrade lets say B (destruct B,C call compile_object in Cx and E), 
what I don't see is a possibility to figure for an upgrade command which 
objects have to be touched at all. 

One approach I see, would be a breath-first search beginning with B through
all objects which inherit B, destructing Objects which are inherited only
and recompiling those who are cloned only. But for this I had to know
a) All objects inheriting B (in this case C)
b) if an object was cloned (at all)

The lazy approach (speak it lag reducing), to upgrade an object the moment
it gets touched, (either called a function in or get inherited or cloned),
would need a list of objects beeing inherited in the object. In this example
for D i need to know (A,B,C,Cx). Everytime an object get's called you had to
check if one of those objects was upgraded and initiate an upgrade for all
objects on the path to D (in the scenario given above (B was upgraded)
this means - destruct C and Cx. Even if I knew about this, this looks as 
if call_other would be pretty expensive, at least in deeply structured 
situations.

> 
> However, I'm not sure how to deal with the calling of functions in a
> master.  I imagine we could overload call_other as I think the
> {ob|file}->fn call uses call_other.  Correct me if I'm wrong.  I think
> someone with some more knowledge of how the function calling works needs
> to finish this off ;)

If calling a function in a master is prohibited, you should perhaps provide
some functions (in auto_object) or macros (in an includefile) which make sure
you have a special clone representing the master for function calling. A 
hypothetic function CALL_MASTER would have to make sure there is this special
clone (if not create it) and call this clone instead. (The cloning of course
had to make sure the master is not in "mixed" use. You could use the Cx 
approach here.) 

upgrading should then be possible again.


greetings Ludger

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