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.