Author: Ulrich Schoebel <ulrich.schoebel@sigos.de>
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.