TIP: 142 Title: Search Path Variable to Lookup Command Names in Namespaces Version: $Revision: 1.3 $ Author: Ulrich Schoebel Tcl-Version: 8.5 State: Withdrawn Type: Project Vote: Pending Created: 23-Jul-2003 Post-History: Keywords: namespace, command lookup, search path ~ Abstract This TIP adds a Tcl variable to define the search path for command name lookup across namespaces. ~ Rationale Command names (as well as variable names) are currently looked up first in the current namspace, then, if not found, in the global namespace. It is often very useful to hide the commands defined in a subnamespace from being visible from upper namespaces by ''info commands namespace::*''. On the other hand, programmers want to use these commands without having to type a qualified name. * Example: | namespace eval ns1 { | proc p1 {} { | puts "[p2]" | } | } | | namespace eval ns1::ns2 { | proc p2 {} { | return hello | } | } Evaluation of ''ns1::p1'' would currently lead to an error, because ''p2'' could not be found. Even worse, if a procedure ''p2'' exists in the global namespace, the wrong procedure would be evaluated. ~ Proposal Add a variable ''tcl_namespacePath'' or, to avoid confusion with variables containing file system paths, ''tcl_namespaceSearch'', that contains a list of namespaces to be searched in that order. The default value would be ''[[list [[namespace current]] ::]]''. In the above example ''tcl_namespacePath'' would be set to ''[[list [[namespace current]] [[namespace current]]::ns2]]''. ''p2'' would be found and not unintentionally be substituted by ''::p2''. ~ Alternative For ease of implementation and, maybe, for programmers convenience it might be useful to always prepend the contents of this variable with ''[[namespace current]]''. The programmer expects a certain "automatism" for this component of the search path. Then the default value would be ''::''. ~ Implementation To be done when this TIP is accepted. ~ Notice of Withdrawal This TIP was Withdrawn by the TIP Editor following discussion on the tcl-core mailing list. The following is a summary of reasons for withdrawal: > Insufficiently subtle. 52 will break any code that assumes the current behaviour (and you can bet someone will have that assumption) and 142 doesn't let two namespaces have different search paths (unless the variable is always interpreted locally, which just creates bizarre variable name magic.) ~ Copyright This document is placed in the public domain.