Ticket UUID: | 1436096 | |||
Title: | unqualified cmd names in ensemble dicts | |||
Type: | Bug | Version: | obsolete: 8.5a4 | |
Submitter: | dgp | Created on: | 2006-02-21 18:39:39 | |
Subsystem: | 21. [namespace] | Assigned To: | dgp | |
Priority: | 9 Immediate | Severity: | ||
Status: | Closed | Last Modified: | 2007-11-28 23:50:29 | |
Resolution: | Fixed | Closed By: | dgp | |
Closed on: | 2007-11-28 16:50:29 | |||
Description: |
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?) | |||
User Comments: |
dgp added on 2007-11-28 23:50:29:
Logged In: YES user_id=80530 Originator: YES committed for 8.5.0 dgp added on 2007-11-28 23:46:04: File Added - 256457: 1436096.patch Logged In: YES user_id=80530 Originator: YES Here's a patch File Added: 1436096.patch dgp added on 2007-11-02 00:55:19: 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? dkf added on 2007-11-01 04:36:45: 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. msofer added on 2007-11-01 00:12:03: 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). dgp added on 2007-09-05 23:22:50: 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. msofer added on 2006-10-17 02:19:23: Logged In: YES user_id=148712 Taking over: possible resolution with TIP 283. dgp added on 2006-04-17 22:41:20: 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. dkf added on 2006-04-17 22:33:26: 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.) |
Attachments:
- 1436096.patch [download] added by dgp on 2007-11-28 23:46:04. [details]