Re: [Xotcl] parameters vs slots and use of "-initcmd"
Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 03 Jul 2007 20:08:07 +0200
Dear Nico,
Nico L'INSALATA (UniPI) schrieb:
> I need some clarifications regarding the use of Class parameters and
> Class slots (I will refer to v.1.5.2 of the XOTcl tutorial).
> Parameters are used throughout the introduction of the tutorial to model
> Class attributes, then slots are introduced in a later section. Are
> slots and parameters actually the same thing? Is there some reason to
> prefer one over the other?
>
historically in xotcl, parameter predate slots. since xotcl 1.5.0, all
parameters are
implemented as slots. slots are more powerful, parameters are sometimes
more
more handy to use.
> Anyway, I've started using slots and I got lost using the -initcmd feature.
> This is a "simplified" version of the code that "doesn't work" (i.e.
> I'm not able to make it work :-) )
>
> Class my_class \
> -slots {
> Attribute one -type integer -default { 0 }
> Attribute two -type integer -default { 0 }
> Attribute three -type integer -initcmd {
> if { [my one] > [my two]} {
> set _ 100
> } else {
> set _ 101010
> }
> }
> }
>
> The code doesn't work (of course!!) since [self] within initcmd has
> value "::my_class::slot::three".
yes, this is exactly the probem. slots are manager objects for managing
other objects instance variables. but maybe the initcmd should be evaluated
in the scope of the object...
> So, the question is: how do I refer to
> other attributes of the same class from within -initcmd { }?
>
i would not recommend to follow the approach sketched above.
in general, you have no control over the order in which the instance
variables are instantiated. therefore, the slot definitions are not
a valid instrument for defining attributes based on the values of other
attributes. use the constructor method (init) for such purposes
Class my_class -slots {
Attribute one -type integer -default { 0 }
Attribute two -type integer -default { 0 }
Attribute three -type integer
}
my_class instproc init {} {
my three [expr {[my one] > [my two] ? 100 : 101010}]
}
> And secondarily, is it possible to associate -initcmd with an instproc
> of the class in which the attribute is being defined? e.g. an instproc
> of Class my_class
>
this is a very sensible request independent from the attribute dependencies
above. Replace in predefined.xotcl the two methods __default_from_cmd
and __value_from_cmd as shown below, and the [self] in initcmd
will point to the object. One test of the regression test will change its
results, but you can safely ignore this.
Unless i learn from experience that the change below is not a good
idea, this modification will go into the next release of xotcl. There
will be a bug-fix release 1.5.4 before the next major release comes
out with much higher orthogonality and more slot features.
-gustaf neumann
::xotcl::Attribute instproc __default_from_cmd {obj cmd var sub op} {
#puts "GETVAR [self proc] obj=$obj cmd=$cmd, var=$var, op=$op"
$obj trace remove variable $var $op [list [self] [self proc] $obj $cmd]
$obj set $var [$obj eval $cmd]
}
::xotcl::Attribute instproc __value_from_cmd {obj cmd var sub op} {
#puts "GETVAR [self proc] obj=$obj cmd=$cmd, var=$var, op=$op"
$obj set $var [$obj eval $cmd]
}
Date: Tue, 03 Jul 2007 20:08:07 +0200
Dear Nico,
Nico L'INSALATA (UniPI) schrieb:
> I need some clarifications regarding the use of Class parameters and
> Class slots (I will refer to v.1.5.2 of the XOTcl tutorial).
> Parameters are used throughout the introduction of the tutorial to model
> Class attributes, then slots are introduced in a later section. Are
> slots and parameters actually the same thing? Is there some reason to
> prefer one over the other?
>
historically in xotcl, parameter predate slots. since xotcl 1.5.0, all
parameters are
implemented as slots. slots are more powerful, parameters are sometimes
more
more handy to use.
> Anyway, I've started using slots and I got lost using the -initcmd feature.
> This is a "simplified" version of the code that "doesn't work" (i.e.
> I'm not able to make it work :-) )
>
> Class my_class \
> -slots {
> Attribute one -type integer -default { 0 }
> Attribute two -type integer -default { 0 }
> Attribute three -type integer -initcmd {
> if { [my one] > [my two]} {
> set _ 100
> } else {
> set _ 101010
> }
> }
> }
>
> The code doesn't work (of course!!) since [self] within initcmd has
> value "::my_class::slot::three".
yes, this is exactly the probem. slots are manager objects for managing
other objects instance variables. but maybe the initcmd should be evaluated
in the scope of the object...
> So, the question is: how do I refer to
> other attributes of the same class from within -initcmd { }?
>
i would not recommend to follow the approach sketched above.
in general, you have no control over the order in which the instance
variables are instantiated. therefore, the slot definitions are not
a valid instrument for defining attributes based on the values of other
attributes. use the constructor method (init) for such purposes
Class my_class -slots {
Attribute one -type integer -default { 0 }
Attribute two -type integer -default { 0 }
Attribute three -type integer
}
my_class instproc init {} {
my three [expr {[my one] > [my two] ? 100 : 101010}]
}
> And secondarily, is it possible to associate -initcmd with an instproc
> of the class in which the attribute is being defined? e.g. an instproc
> of Class my_class
>
this is a very sensible request independent from the attribute dependencies
above. Replace in predefined.xotcl the two methods __default_from_cmd
and __value_from_cmd as shown below, and the [self] in initcmd
will point to the object. One test of the regression test will change its
results, but you can safely ignore this.
Unless i learn from experience that the change below is not a good
idea, this modification will go into the next release of xotcl. There
will be a bug-fix release 1.5.4 before the next major release comes
out with much higher orthogonality and more slot features.
-gustaf neumann
::xotcl::Attribute instproc __default_from_cmd {obj cmd var sub op} {
#puts "GETVAR [self proc] obj=$obj cmd=$cmd, var=$var, op=$op"
$obj trace remove variable $var $op [list [self] [self proc] $obj $cmd]
$obj set $var [$obj eval $cmd]
}
::xotcl::Attribute instproc __value_from_cmd {obj cmd var sub op} {
#puts "GETVAR [self proc] obj=$obj cmd=$cmd, var=$var, op=$op"
$obj set $var [$obj eval $cmd]
}
