Hi,
On Tue, 26 Dec 2000 seva@design.kiev.ua wrote:
I split my application in several source files. Each of files implements one of fsm's or helper functions, and when I need to change logic of work, i simply source all files.
There are several problems with this:
- when I execute command Class Some, previous instance of this
class deleted, and all objects move to ::Object class.
this behavior is intended: from a "programming language point of view" you can not predict whether a destroyed class is going to be redefined or not. There could be another class with the same name, but with different semantics.
In cases like your application, that require a class redefinition, there are several ways to tell the language to behave like this:
- you can use the filter, as you have done to overload create. - you can use a subclass or a mixin to change create bahavior - or you use introspection to find out which instances are currently there and re-class these instances after sourcing to the new classes (same-named) classes
Probably a combination would work here, like a instmixin on object that checks whether a class-to-be-created exists. If yes all instances are stored in a variable. After create, the instances are re-classed back to the old class.
Or you build an instmixin tht simply does not execute the "create" on certain existing classes?
It depends on your application case which solution is the best here ...
This problem I solve by using filter for create command on ::Object (ideastolen from recoverypoint class :)) ). But with that second problem arrives: 2) when some instproc used as a filter, and redefined, it's filter become inactive. (so first problem arrives again, when I source recover.tcl which has recoverfilter definition) after setting filter again, all works as expected
for the same reason as we have to re-class exisiting instances, we have to set the filters to an empty list, when the method is redefined (the same is done for mixins, when the class is redefined). E.g., we can not say that in any case with "Object instproc filter" the same method is defined. But again you can easily change this behavior for certain cases with a filter or instmixin or a subclass of Object, by redefining "mixin", "instmixin", "filter", etc. so that they check whether a certain filter, mixin, or instmixin is still there. A filter on Object is probably not the best solution here, because it performs the check on every call in the system. This is a heavy performance overhead. Presumably a mixin solution is more well-suited, because it only checks for certain methods and can be used object-specifically.
In your example code a "mixin" on "Class", that just checks the Class->create method could be sufficient.
Hope this helps,
Uwe
-- Uwe Zdun Specification of Software Systems, University of Essen Phone: +49 201 81 00 332, Fax: +49 201 81 00 398 zdun@xotcl.org, uwe.zdun@uni-essen.de