#1572 [namespace which -var] ignores aliases

[Don Porter]

% namespace eval foo variable x 1
% namespace eval bar variable x 2
% proc bar::test {} {
variable ::foo::x ;# 'x' is now an alias for
;# ::foo::x
set x 3 ;# sets ::foo::x
puts "x is [namespace which -variable x]"
}
% bar::test
x is ::bar::x
% set bar::x
2
% set foo::x
3

This is not what I expect. I expect
[namespace which -variable x] to tell
me something about what "x" refers to
in the current context. But [namespace which]
is completely ignoring the local alias "x"
and telling me how it would resolve "x"
looking in the current and global namespaces
only. That has nothing to do with how operations
on "x" will behave, which is what I really want
to know.

Here the local variable alias was created with
[variable], but the same problem exists when
local variables are created with [upvar] or
just by creating a local variable.

As is, [namespace which] is not the tool I need.
The tool I need appears to be missing. What
I need is the analog of [namespace origin] for
variables.

[Don Porter]

Logged In: YES
user_id=80530

After chat discussions with Miguel, it seems
there's both a bug and a feature request here.

[namespace which -variable] should reflect the
actual resolution rules. As is, when called
inside a proc, it doesn't examine the local context
at all. Also, when the variable name does not
contain any namespace qualifiers, it's resolution
will not involve other namespaces at all, yet
[namespace which -var] will still act like it does.

In the example, it would be better to see

% bar::test
x is x

Indicating that in the context of the body of
proc [bar::test], "x" is a local variable, and
won't be resolved in other namespaces.

In addition, we need the ability to determine the
ultimate reference of local variables that are
really aliases created by [upvar], [variable],
etc. That's the Feature Request part, and will
need some thinking. (What about references to
other proc contexts?, etc.)

[Don Porter]

Logged In: YES
user_id=80530

kbk is cooking up something
along these lines.

[Kevin B KENNY]

Logged In: YES
user_id=99768

Hardly "cooking up". I mentioned that we really could use a
way to resolve a variable to a canonical name (plus stack frame
level if the variable is proc-local). Several of us that
were on
the Chat did some spelunking in the code, and discovered that
the desired functionality would founder in the case where a
scalar variable was an alias to an array element; fixing the
issue would be a big change because it would change the
size of the Variable struct. RFE 572889 is essentially the
same issue, but applied to [trace]. There is another bug or
two that would need this kind of handling.

I didn't have any implementation in the works for this. Sorry.

[Don Porter]

Logged In: YES
user_id=80530

Just hit this again. AAARRRRRGGGGGHHHHH!!!!!!!

"[namespace which] is not the tool I need.
The tool I need appears to be missing. What
I need is the analog of [namespace origin] for
variables."