#447 TIP 283: ensemble's command resolution

[miguel sofer]

[namespace unknown] should be able to follow [namespace
path] and [namespace unknown] lookup behaviour.

After application of [Patch 1577278], adding a line
iPtr->lookupNsPtr = ensemblePtr->nsPtr;
just before the call to Tcl_EvalObjv in
NamespaceImplementationCmd enables this behaviour.

If the registered ensemble unknownProc returns a FQ
command as first element of the list, the resolution is
still global. If the name is not FQ, the resolution
will follow whatever rules the ensemble's namespace has
set in place.

[miguel sofer]

Logged In: YES
user_id=148712

Patch for docs and tests attached

[miguel sofer]

[miguel sofer]

[miguel sofer]

Logged In: YES
user_id=148712

Updated patch: code, docs, (incomplete) tests

[miguel sofer]

Logged In: YES
user_id=148712

Updated patch that works in HEAD. It breaks test cmdAH-24.12
in a weird manner - by breaking autoloading of [clock scan].
The reason is exposed below; the problem with clock can be
fixed easily, but the wider problem may be more important.

*** DANGER ***

As the "fix" for [info level] in HEAD was reverted (Bug
1577492, previously called "let [info level] know ensemble
rewrites"), this new feature breaks nother usual idiom.

'uplevel 1 [info level 0]' is NOT GUARANTEED to call the
present proc again

This is because:
(a) 'namespace ensemble' does not push a new frame
(b) 'namespace ensemble' calls by simple name (non qualified)
(c) 'info level 0' reflects only the actual call, ie, a
simple name

As an illustration, with this patch we get:

% namespace eval a {
variable ct 0
namespace ensemble create -map {x scan}
proc scan args {
variable ct
if {$ct} {
puts YES
return
}
incr ct
uplevel 1 [info level 0]
}
}
% a x
wrong # args: should be "scan string format ?varName varName
...?"

[miguel sofer]

[Donal K. Fellows]

The NRE-enabled command dispatch function allows control over the command resolution context. Might be worth looking at whether this FRQ can be dealt with through that route.