#5035 ensemble namespace wackiness

[Lars Hellström]

Today, I have encountered some curious details concerning the -map of [namespace ensemble]. The first thing, which is quite reasonable although a surprise to me as it does not seem to be mentioned in the manpage, is that all prefixes in the -map option will be made fully qualified whenever they are set. The second thing, which seems more questionable, is that they are always qualified using the current namespace rather than the namespace of the ensemble. The following modified test illustrates my expectation and the current outcome:

==== namespace-46.9 ensemble: configuring really configures things FAILED
==== Contents of test case:

namespace eval ns {
namespace ensemble create -map {a a} -prefixes 0
}
set result [list [catch {ns x} msg] $msg]
lappend result [namespace ensemble configure ns -map] ; # Added
namespace ensemble configure ns -map {b b}
lappend result [catch {ns x} msg] $msg
lappend result [namespace ensemble configure ns -map] ; # Added
namespace delete ns
set result

---- Result was:
1 {unknown subcommand "x": must be a} {a ::ns::a} 1 {unknown subcommand "x": must be b} {b ::b}
---- Result should have been (exact matching):
1 {unknown subcommand "x": must be a} {a ::ns::a} 1 {unknown subcommand "x": must be b} {b ::ns::b}
==== namespace-46.9 FAILED

What seems wacky to me is that if I've created an ensemble using one value for -map, and then reconfigure it using the exact same value for -map (or perhaps more commonly some slight extension of same), then I will only get the same mapping of commands if I also issue the call from within the exact same namespace as I started with; I would rather expect that the -namespace namespace should be used, as it is for resolving -subcommands without an explicit -map entry.

That said, I'm not sure that the behaviour is necessarily useless; I can see

namespace ensemble configure $cmd -map [dict merge [namespace ensemble configure $cmd -map] {
more mappings
}]

being a potentially useful idiom for extending an ensemble with commands from a different namespace without having to fully qualify them explicitly, but whether it could be considered reliable behaviour is an open question: it's not mentioned in the manpage, and there does not seem to be any tests supporting that this is expected behaviour either.

The practical cause of all this seems to be that TclNamespaceEnsembleCmd goes

Namespace *nsPtr = (Namespace *) TclGetCurrentNamespace(interp);

(tclEnsemble.c line 111) and takes this as specifying the namespace to operate in also for the ENS_CONFIG branch of the function. The subsequent check (lines 117--124)

if (nsPtr == NULL || nsPtr->flags & NS_DYING) {
if (!Tcl_InterpDeleted(interp)) {
Tcl_AppendResult(interp,
"tried to manipulate ensemble of deleted namespace",
NULL);
}
return TCL_ERROR;
}

does however seem a bit out of place if nsPtr is always supposed to refer to the current interpreter namespace, so I'm inclined to hypothesise that this arose more out of accident than out of design.

[Lars Hellström]

OK, shorter summary:

1. When you [namespace ensemble configure -map] something, it fully qualifies the prefixes using the current namespace, not the -namespace of the ensemble. I think this is a *bug*.

2. That prefixes are always stored fully qualified actually isn't mentioned in the manpage. I think it should be.

[Donal K. Fellows]

Re 1, that's _deliberate_. The names have to be qualified in order to get stable behavior anyway, and qualifying using the current namespace is the most flexible reasonable option. (You can use [namespace eval] to help select namespaces.)

Re 2, OK, documentation needed.