Menu
▾
▴
#3372 unqualified cmd names in ensemble dicts
Not completely confident about
this one...
It appears that for ensemble
subcommand dispatch to work
correctly, the command name
needs to be fully qualified.
Implementation of the
[namespace ensemble] command
appears to go to significant
effort to store only fully
qualified commands. (patchedDict
and all that).
However, the public routine
Tcl_SetEnsembleMappingDict()
permits registration of a
dictionary with unqulified cmds
in it. I think this will break
subcommand resolution, due to
the used of TCL_EVAL_INVOKE.
Feel free to close this invalid
if I'm just missing something.
(Is the *real* fix here to factor
TCL_EVAL_INVOKE into useful
subfunctions? Separate flags for
suppressing ::errorInfo appends
and for command resolution in the
global namespace?)
Logged In: YES
user_id=79902
Other kinds of command resolution can be implemented as
commands, you know. For example, fully unqualified:
proc ::uqeval args { uplevel 1 $args }
dict set map bar [list ::uqeval bar]
namespace ensemble configure foo -map $map
Given that, solving this isn't a high priority right now.
(The alternative is to have some mechanism for specifying
what NS to use when resolving a command, but I'm not quite
sure how to make that all tie together.)
Logged In: YES
user_id=80530
Yes, my point was to question
whether Tcl_SetEnsembleMappingDict()
ought to be public, or if public,
whether it ought to reject
non-fully-qualified subcommand
handlers. As you point out, if
we did add such a constraint to
the interface, coders could still
achieve whatever resolution rules
they want.
Logged In: YES
user_id=148712
Taking over: possible resolution with TIP 283.
Logged In: YES
user_id=80530
Originator: YES
This looks like something
to be sure we have resolved
for beta, since fixing it
might involve mods to the
public API.
Logged In: YES
user_id=148712
Originator: NO
Agreed, but I do not know how to fix this without breaking other stuff. Specifically, the behaviour caused by TCL_EVAL_INVOKE where a command name is resolved in a special context, but the command is then invoked from the caller's context, subtly breaks [uplevel] expectations (and [unknown]). In particular
uplevel 1 [info level 0]
may fail to call the current proc - as the lookup will now proceed in the caller's context and not in the special context required by TCL_EVAL_INVOKE. Consider
% proc a args {namespace eval ::a $args}
% a proc tell args {info level 0}
% a namespace export tell
% a namespace ensemble create -command ::foo
::foo
% foo tell
::a::tell
If the result were 'tell' the effect above would occur.
This behaviour is already problematic in [interp alias], in a milder form: the lookup is done in a previsible context (global).
Logged In: YES
user_id=79902
Originator: NO
Hmm, then we've got to just pick which bits to keep.
I reckon we must preserve the fact that [uplevel 1 $script] runs in the context of the caller of the overall ensemble. Far more scripts are dependent on that than on [info level 0] or on [unknown]'s autoloading these days - lazy package loading is bad for other reasons too - and without preserving that chaos will reign when you wrap a command that really relies on that. (This is one of the things that is wrong with xotcl.)
We can also make [info level 0] say how to call the command again so that [uplevel 1 [info level 0]] repeats the current command, called in the same way. But we can't keep all that without breaking [unknown]. We get to pick: square or circle, but not both.
Logged In: YES
user_id=80530
Originator: YES
I'm missing something then?
Why wouldn't a Tcl_SetEnsembleMappingDict()
that either rejects unqualified names,
or qualifies them before storing take
care of this issue?
Logged In: YES
user_id=80530
Originator: YES
Here's a patch
File Added: 1436096.patch
Logged In: YES
user_id=80530
Originator: YES
committed for 8.5.0