#3054 Tcl_FindCommand: bogus comment?

[Don Porter]

A comment following the "name"
argument to Tcl_FindCommand
claims:

"If it starts with "::", will be looked
up in global namespace."

Since custom resolvers are given
first crack at the resolving task,
and since they are apparently
free to resolve names matching
::* however they like, I think
this comment is false.

[Don Porter]

Logged In: YES
user_id=80530

Completing the thought, if
a Tcl_FindCommand() caller
wants to force resolution in
the global namespace, it should
use the TCL_GLOBAL_ONLY
flag to accomplish that.

[Don Porter]

Logged In: YES
user_id=80530

there may be a lurking
inconsistency here with
Tcl_GetCommandFromObj()
where commands beginning
with "::" *do* get special treatment.

[Don Porter]

Logged In: YES
user_id=80530

ok, so I'm closing in on
the opinion that the comment
*ought* to be true, and the
bug here is that the current
implementation of
Tcl_FindCommand allows
custom resolvers to
interpret a fully qualified
command name to mean something
other than its plain meaning.
It appears this possibility is
inconsistent with assumptions
in other parts of Tcl.

[miguel sofer]

Logged In: YES
user_id=148712
Originator: NO

No inconsistency there: SetCmdNameFromAny calls Tcl_FindCommand to determine the command.

What may be problematic is that the cmdName stores the global ns as the origin of the search for FQ names. This would cause buggy behaviour if
(a) a namespace ns has a resolver that redirects FQ names
(b) an FQ command ::cmdA is searched starting from ns, and resolved to (say) ::B
(c) ::cmdA is resolved starting from elsewhere; the cached pointer to ::B will be used

I agree that eventually the "correct" behaviour may be for FQ names to bypass all resolvers. Chose a "conservative" fix for now: insure that Tcl_FindCommand starts the search for FQ commands in the global ns. The difference is that resolvers on the global namespace or interp wide resolvers will be called.

Tests show that itcl, xotcl and TclOO do not mind.