[DGD]Object Upgrading Scenario
Jason Cone
jcone at uscdev.com
Thu Jan 6 02:31:21 CET 2000
[NOTE -- I sent this message earlier without giving thought to the fact that
I changed email addresses. If it arrives twice, I apologize. Anyway,
original message follows.]
Greetings, all.
A friend and I have been dialoging for some now on the various
implementations of object upgrading and are just now getting to the stage
where we can start implementing such a system. We have it worked out pretty
well in theory save one scenario. Granted, the following scenario is a
product of bad design (allowing inheritable objects to be cloned), but it'd
be nice to have an implementation that could function in the face of flawed
object inheritance rules.
Anyway, let assume the following object relationships:
A -i-> B -i-> C -c-> D
A -i-> B -i-> C -i-> E -c-> F
This notation should read, "Object D is a clone of object C which inherits
B, which inherits A. Object F is a clone of object E which inherits object
C."
Bad design issues aside, what is a possible implementation that could take
object E into account? If E (and, consequently, F) didn't exist, an
overloaded compile_object() function would do the following:
destruct_object(A)
destruct_object(B)
::compile_object(C)
This would then allow for the single/multiple D object(s) to take advantage
of the new functionality that was added to A. That approach, however, would
really mess things up if it used the same approach when trying to upgrade E
(F) -- ::compile_object() could not be called on object C as E inherits C
(would yield a run-time error).
Thoughts?
I know this subject has been beaten to death, but since we're running across
this issue during the implementation stage, my hope is that we can share a
successful implementation with everyone and not just discuss it on a
hypothetical issue. I would like this scenario resolved, though, if
possible. :)
Thanks.
Jason Cone
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list