TIP229: namespace path

Logged In: YES
user_id=148712

I'm worried about the speed implications, as I do not
immediately see how the core can cache already resolved
command names and insure that the cached values are correct.
The problem is (un)shadowing of commands at different levels
in the search path. The test namespace-51.5 (added in the
patch as knownbug) illustrates the point.

One possibility is to disable caching selectively: commands
called from a namespace that has a non-empty search path are
only cached if they reside in that namespace.

Later on, we may design a mechanism to cache all commands
and detect shadowing/unshadowing effects. I am not sure if
this can be done reasonably in presence of dynamic paths.
The core currently does this, but with fixed search paths of
length 2 (as given by Tcl's resolution rules).

Logged In: YES
user_id=79902

Here's an updated version.

Resolution cacheing is implemented (and in fact the main
problem has been over-eager cacheing, not insufficient
cacheing!) as is a bunch of issues relating to what happens
in tricky lifetime-management cases. Everything's also now
object-aware, and errors relating to unknown namespaces are
generated early.

Logged In: YES
user_id=79902

And another version, with cleaner internal API (possibly
worth exposing in the future) and more extensive testing.

Logged In: YES
user_id=79902

ToDo: Fix InfoCommandsCmd in tclCmdIL.c; when the pattern is
namespace-less, need to add all (matching) commands from the
whole path.

Logged In: YES
user_id=80530

One really minor quibble with the
new namespace-51.* tests.
They assume the -body of each test
will run in the global namespace. These
tests will be more robust if they do their
own [namespace eval :: {...}].

Logged In: YES
user_id=79902

Update to handle more of dgp's wish-list.

No docs yet.

Patch v5

Logged In: YES
user_id=79902

Implementation (based on patch here) checked into HEAD