TIP 142: Search Path Variable to Lookup Command Names in Namespaces

Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2017 Conference, Houston/TX, US, Oct 16-20
Send your abstracts to tclconference@googlegroups.com
by Aug 21.
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.

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.

History