Dear Kurt,
Replace in the assign method $obj set $var [list $obj $var $val]
by $obj set $var [::list $obj $var $val]
Background: the created slot object2 ("alist" and "list") are fully named
::Test1::slot::alist ::Test1::slot::list
In order to create these conveniantely (i.e. without requiring the user to write the namespaces explicitly), the method "slots" changes the current namespace to "::Test1::slot". The method "assign" is executed in this namespace (::Test1::slot), and picks up the "::Test1::slot::list" instead of the desired "::list". Therefore, using the explicit namespace path for "::list" helps.
The only way to get rid of this unexpected behavior is to introduce a namespace resolver for the slot object container, that overrides the Tcl behavior.
-gustaf neumann
On 25.06.12 00:54, Kurt Stoll wrote:
This looks wrong to me, but I could be wrong - maybe there are prohibitions somewhere that would tell me not to do this.
If I define an Attribute "list", and then use the Tcl list command within the assign (and, presumably, other procs of the attribute as well), the attribute's unknown handler is called reflecting an odd invocation. I would suspect that other "overloading" (this is not really overloading, but looks similar so I have used that term; I apologize it that confuses you) of Tcl commands as Attributes would result in similar problems.
First, here is a simple Test class without overloading the list command to demonstrate the expected behavior. Note that I redefine unknown so that I can verify the order of the invocation:
(Warning - I submitted a question with embedded test code some years ago and this caused problems for people when they attempted to copy-and-paste the code. I don't recall exactly what caused the issue, but I am still using the same email client, so this may have similar issues.)
Class create Test1 -slots { Attribute create alist -proc assign { obj var val } { puts "list<$obj> <$var> <$val>" $obj set $var [list $obj $var $val] } -proc unknown { val obj var args } { puts "unknown: $obj $var $val $args" } }
## Create a test object t1 Test1 create t1
::t1
## Call alist setter t1 alist 3
list<::t1> <alist> <3> ::t1 alist 3
## Check to see that alist variable set properly t1 set alist
::t1 alist 3
## Force a call to unknown; note that the printed output matches the invocation order t1 alist this should call unknown
unknown: ::t1 alist this should call unknown
Now, I create a simple variant. All I have changed is the name of the Attribute from "alist" to "list". But, in this case, when attempting to call the setter, unknown is called (I have done other experiments that showed that it is called when "list $obj $var $val" is called). Also, note that the invocation of unknown is a bit strange; it appears that unknown is directly invoked on the original call (in this case, "t2 list 3"), instead of having the arguments swapped as demonstrated above:
Class create Test2 -slots { Attribute create list -proc assign { obj var val } { puts "list<$obj> <$var> <$val>" $obj set $var [list $obj $var $val] } -proc unknown { val obj var args } { puts "unknown: $obj $var $val $args" } }
## Create a test object t2 Test2 create t2
::t2
## Call list setter. Unknown handler is called. t2 list 3
list<::t2> <list> <3> unknown: list 3 ::t2
## See what ended up in the list variable. t2 set list ## Blank above
Am I wrong to expect Test2 (and t2) to behave just as Test1 / t1 behaved? It's not a serious issue for me; I'll just avoid overloading Tcl commands in this context. But, it was unexpected enough for me that I thought it was warranted for me to ask the experts.
-Kurt Stoll
Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl