"seva" == seva seva@design.kiev.ua writes:
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.
seva> Ok, I agree with that point :)) (But does'nt like it too much :)) )
We have discussed the redefinition of Classes recently, and we are thinking about ways to improve it. However, for the time being you can use something like the following (take care, this version is very simplistic and assumes that the new class is defined exactly like the original
=============================================================== # The following create method is non-destructive, it lets # exiting classes untouched Class CheckCreate CheckCreate instproc create {cn args} { puts "[self] [self proc] $cn <$args>" if {[[self] isclass $cn]} { puts "Dont redefine $cn, ignore '$args'" } else { next } } #overload create of the Metaclass Class mixin CheckCreate ===============================================================
you can use it later like in the following example: the create method, which is implicitly invoked, does not delete the old class in cases it exists already....
=============================================================== Class A Class B -superclass A B a
foreach i {instances heritage} {puts "$i of B:\t[B info $i]"} puts stderr ============= Class B -superclass A foreach i {instances heritage} {puts "$i of B:\t[B info $i]"} ===============================================================
I would expect that the solution above is quite similar to what you have already achieved via filters....
The redefine problem of the filter method, that you mention in your mail, looks like a bug to me, that we should fix in the next release. In the meantime, you should be able to use something like the following: you can redefine "instproc" to check, whether the new definition of a method is a definition of a filter, and if yes, you can register the filter again automatically. For simplicity, the following piece of code assumes, that the filter is defined in the same class for which it is registered.
========================================================================== # The following instproc method circumvents a bug in XOTcl 0.84 # and earlier Class FilterInstproc FilterInstproc instproc instproc {name args} { set filters [[self] info filter] next if {[lsearch $filters $name]>-1} { puts "redefined filter $name" [self] filter $filters } } # overload insproc Object instmixin FilterInstproc ==========================================================================
with this definition, your example will work as expected.....
best regards
-gustaf neumann