[DGD]Object Upgrading Scenario

[Neil McBride]

> 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).

That's spot on. I actually meant to put that in ;)

> 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.

I would think doing such a check every time an object is touched could
end up being very expensive, as the whole inheritence tree needs to be
followed, all the way back to the auto.  Doing this everytime a function
is called in an object, and I'm sure you can see the load this would
generate.  Compare this to the option of following the inheritence tree
when a master object is updated.  The load, as far as I can see would be
a lot less.

> 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.)

I was thinking that this could be used by making every clone follow the
Cx example.  This of course leaves a lot of extra files around, and gets
very very messy.  Can you get access to the tmp directory specified by
the DGD config file from within the lib?  This would quickly become
cluttered otherwise ;)

Cheers,

Neil.

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