No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] Re: [Xotcl] problem: filter disappears if instproc redefined
From: Uwe Zdun <uzdun_at_k2.informatik.uni-essen.de>
Date: Thu, 28 Dec 2000 15:27:00 +0100 (CET)
Hi,
On Tue, 26 Dec 2000 seva_at_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:
> 1) 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 (idea
> stolen 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
Date: Thu, 28 Dec 2000 15:27:00 +0100 (CET)
Hi,
On Tue, 26 Dec 2000 seva_at_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:
> 1) 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 (idea
> stolen 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_at_xotcl.org, uwe.zdun_at_uni-essen.de