Dear victor,
There is a difference/asymmetry between "namespace path" and "namespace import"
* "namespace import" creates cmd-stubs in the actual namespace (if issued on "::", in the top-level namespace). The default rule for function resolving checks the contents of the top-level namespace as a final resort.
* "namespace path" adds a searchpath to the current namespace, but this is apparently not used as "final resort rule".
Look at the following test script, which is pure tcl: - the namespace ::tst contains two procs, f-1 is namespace-imported to top, f-2 not (just namespace-pathed). - Both are seen by a toplevel "info command", both can be executed on top. - in the ::app-namespace, we have no namespace path. We can call f-1, but not f-2
=================================== namespace eval ::tst { proc f-1 {} { return f-1 } proc f-2 {} { return f-2 } namespace export f-1 f-2 }
namespace path tst namespace import tst::f-1 puts f-1=[namespace which f-1] puts f-2=[namespace which f-2] puts "we see: [info command f-*]"
namespace eval ::app { proc foo {} { puts [namespace current]//[namespace path] puts f-1=[namespace which f-1] puts f-2=[namespace which f-2] f-1 f-2 } }
::app::foo ===================================
Exactly the same happens in "a::b tst", since "::a" is an object with object-specific methods and establishes a tcl namespace.
% Object create a ::a % Object create a::b ::a::b % a public method tst args {puts [self]}; ::a::tst % a::b public method tst args {puts [self]}; ::a::b::tst % a tst ::a % a::b tst ::a::b %
One could add a namespace path to "::a", but an application writer does most probably not like to do this. One could automatically mangle the default namespace paths (or use special resolvers) from nx/xotcl, but that could as well lead to surprising behavior....
Hope, this explains the observed behavior...
-gustaf neumann PS: namespace path came already with tcl 8.5