#3372 unqualified cmd names in ensemble dicts

obsolete: 8.5a4
closed-fixed
9
2007-11-28
2006-02-21
Don Porter
No

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?)

Discussion

  • Donal K. Fellows

    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.)

     
  • Donal K. Fellows

    • priority: 5 --> 4
     
  • Don Porter

    Don Porter - 2006-04-17

    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.

     
  • miguel sofer

    miguel sofer - 2006-10-16

    Logged In: YES
    user_id=148712

    Taking over: possible resolution with TIP 283.

     
  • miguel sofer

    miguel sofer - 2006-10-16
    • assigned_to: dkf --> msofer
     
  • Don Porter

    Don Porter - 2007-09-05

    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.

     
  • Don Porter

    Don Porter - 2007-10-31
    • priority: 4 --> 9
     
  • miguel sofer

    miguel sofer - 2007-10-31
    • assigned_to: msofer --> dgp
     
  • miguel sofer

    miguel sofer - 2007-10-31

    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).

     
  • Donal K. Fellows

    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.

     
  • Don Porter

    Don Porter - 2007-11-01

    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?

     
  • Don Porter

    Don Porter - 2007-11-28
     
  • Don Porter

    Don Porter - 2007-11-28

    Logged In: YES
    user_id=80530
    Originator: YES

    Here's a patch

    File Added: 1436096.patch

     
  • Don Porter

    Don Porter - 2007-11-28

    Logged In: YES
    user_id=80530
    Originator: YES

    committed for 8.5.0

     
  • Don Porter

    Don Porter - 2007-11-28
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks