View · Search · Index
No registered users in community xowiki
in last 10 minutes

[Xotcl] Re: [Xotcl] Re: [Xotcl] problem: filter disappears if instproc redefined

From: Gustaf Neumann <>
Date: Thu, 28 Dec 2000 19:40:22 +0100 (CET)

>>>>> "seva" == seva <> writes:
>> On Tue, 26 Dec 2000 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.

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 {
#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]
  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