[Tcl-bugs] [ tcl-Bugs-1436096 ] unqualified cmd names in ensemble dicts

[SourceForge.net <no...@so...>]

Bugs item #1436096, was opened at 2006-02-21 18:39
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1436096&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 21. [namespace]
Group: obsolete: 8.5a4
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Don Porter (dgp)
Assigned to: Don Porter (dgp)
Summary: unqualified cmd names in ensemble dicts

Initial Comment:

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




----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2007-10-31 21:36

Message:
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.

----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2007-10-31 17:12

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



----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2007-09-05 17:22

Message:
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.



----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2006-10-16 20:19

Message:
Logged In: YES 
user_id=148712

Taking over: possible resolution with TIP 283.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2006-04-17 16:41

Message:
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.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2006-04-17 16:33

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1436096&group_id=10894