Version 14 of namespace path

: namespace path ?namespaceList?

Returns the path of the current namespace, or sets it to the list of namespaces namespaceList if that argument is given. The path of a namespace is used to “resolve” command names that do not start with a namespace qualifier (i.e., are not fully qualified) when those commands are not present in the current namespace.

wdb This command shows or extends the namespace where an input command is searched in.

In this example, the namespace is extended:

% namespace path "tcl::mathfunc tcl::mathop"
%

Now, you can input math-related commands as follows:

% hypot 3 [+ 2 2]
5.0
%

In this example, the namespace extension is shown.

% namespace path
::tcl::mathfunc ::tcl::mathop
%

Note that the namespaces argument is one proper list. It is not possible to input namespaces as single arguments. (Is it a matter of discussion if that should be possible?)

Note that each namespace (including the global namespace) has a different path. For example:

% namespace eval test {namespace path ::tcl::mathop}
%

inside newly created namespace test, path is extended to ::tcl::mathop. Now, check it out:

% namespace eval test {namespace path}
::tcl::mathop
%

Indeed, path is extended. Now check it in namespace ::

% namespace path
%

In namespace ::, obviously there is no path extension. Check if ::tcl::mathop::+ is known in namespace test:

% namespace eval test {+ 5 6}
11
%

Check the samein namespace :: leads to failure:

% + 5 6
invalid command name "+"
%

JBR - 2011-1223 - Unfortunately the current namespace is always checked, so its not possible to insert a bunch of commands to enhance and override the currently available commands, evaluate a block of code and then remove them. For instance, I have a mini language that I want to execute in the current variable context, but with with some domain specific commands:

   at atX 100

   draw {
        circle $atX 100 -radius 100
   }

I want draw to insert its dsl commands in to the current context and then evaluate the block of code using uplevel to retain the cosy user context, then remove its commands. Using namespace path might have been a nice thing here. But the current namespace is checked first during command resolution so I can enhance the command set but not override it. This is an issue in the global namespace where a lot of generic command names are already being used. So while not likely to be confronted with this in a namespace that you control, the question boils down to:

 "Is it possible to divert command resolution in the global namespace?"

Anyone have any ideas?

Thank - John

Version 14 of namespace path

See also