Hi everybody, my name is Nico and I'm new to XOTcl.
After spending few weeks in understanding the basic concepts of the language, I decided to use it to model one component of the software I'm developing as part of my PhD project (basically, configuration of complex digital hardware macrocells). I've been attracted by XOTcl due to its "aspect oriented" features which are today very common in the hardware design industry.
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?
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". So, the question is: how do I refer to other attributes of the same class from within -initcmd { }?
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
Note that, to ensure things work properly, when instances of my_class are created both attributes "one" and "two" are initialized, while attribute "three" will also be refereed in a subsequent part of the script. This behavior is bizarre and potentially unsafe, but is dictated by another software components over which I have no control.
Thank you very much for your attention!
Nico
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] }
After spending few weeks in understanding the basic concepts of the language, I decided to use it to model one component of the software I'm developing as part of my PhD project (basically, configuration of complex digital hardware macrocells). I've been attracted by XOTcl due to its "aspect oriented" features which are today very common in the hardware design industry.
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?
In early version of XOTcl perameter are just a clever shortcut for method Definition Class A -paramter a
has leaded to method
# setter and getter in one method # something like this A instproc a {args} { if {[llength $args]==0} { my set a } else { my set a [lindex $args 0] } }
It was pure XOTcl and also visible per info instbody. Now parameters are C-coded and probably faster. But it could be better to use old fashioned getter and setter methods, which are well known from Java and Smalltalk. (in Smalltalk all instance variables are private.) Using only method for accessing objects has some advantages (It is more OOP method=message).
A instproc getA { my set a } A instproc setA value { my set a $value }
Methods could be better managed and intercepted per mixins or inheritance. I use XOTcl parameters almost only for true value objects, where I do not need any control about accessing them. Parameters are only syntactic sugar but you do not need to use it.
Artur
Thank you Atur for your introduction. However, i have to add something at certain points:
Artur Trzewik schrieb:
In early version of XOTcl perameter are just a clever shortcut for method Definition Class A -paramter a
has leaded to method
# setter and getter in one method # something like this A instproc a {args} { if {[llength $args]==0} { my set a } else { my set a [lindex $args 0] } }
this is only partially correct, since also in old xotcl versions "parameters" were an abstraction to provide an accessor function and to provide default values.
It was pure XOTcl and also visible per info instbody. Now parameters are C-coded and probably faster.
the c-code provides an accessor function similar to the instproc above (yes, it is about 7 times faster in C). The C-implemented accessor function can be registered via "parametercmd" (or "instparametercmd")
The accessor function above can be replaced by
A instparametercmd a
and can be used via
A create a1 -a 200 puts [a1 a]
The "parametercmd" (without "inst") is used similar to a proc, it registers an accessor function for a single object.
Note, that slots are much more powerful than these kind of parameters, since they are an abstraction for providing much richter meta-data for attributes and can be used for required/non-required attributes, type checking, multi-valued attributes, database attributes, html information (labels, etc), providing meta-data for remoting (e.g. soap calls), and many more.
Parameters are only syntactic sugar but you do not need to use it.
In XOTcl version since 1.5.0, parameters are syntactic suguar for simplified access to slots. In prior versions, they were only syntactic sugar for providing default values and accessor functions.
Strictly speaking, an application programmer does not have to use parameter in the application program, therefore Artur is right.
While the application program does not have to *define* slots, it is hard to do something useful in xotcl without *using* slots since methods like "superclass", "class", "mixin" etc. are implemented as slots.
-gustaf neumann
-
Artur Trzewik -
Gustaf Neumann -
Nico L'INSALATA (UniPI)