namespace eval x {
variable q 123
proc ww {} {
variable q
return $q
}
namespace export ww
}
namespace eval i {
variable q 456
namespace import -force ::x::ww
}Now let us test the proc i::ww and see if we can understand it:% i::ww
123
% info body i::ww
variable q
return $q
% set i::q
456Quite mysterious, if we didn't know that i::ww was defined by namespace import.I don't know if this behaviour should be considered a bug, you just have to be careful, and always do namespace origin before doing info body...wdb: If you import a proc, it always "remembers" where it comes from. You can test it with namespace origin:
% namespace origin ::i::ww ::x::wwThe imported proc ::i::ww behaves as a link to ::x::ww.But, if you rename ::x::ww to ::i::ww, then it really returns the value of ::i::q. So, since its behaviour is understood, it isn't strange any more, is it?
jkock 2006-09-22: in reply to wdb>Thanks for explaining what I already indicated in the last sentence.I don't understand what you want to say with the rename example. What it is meant to explain or justify?wdb: It was not my intent to annoy you. -- My example does not explain but illustrate how the proc behaves: if it is renamed to ::i::ww, then it behaves as if it were originally defined in namespace ::i. Obviously, it is always aware of its name.For an explanation of the behaviour, I'd to look at the C sources. But, I am not willed to learn C. (That's one reason of my decision for Tcl).
jkock: OK, thanks. Within a few days I'll replace our discussion with a summary that sounds like it was written like that in the first place. (I agree with your viewpoint about C --- long live Tcl!) Cheers.
See Also edit
- info
- Playing newLISP
- stooopid info body tricks.

