Re: [TCLCORE] A bug? with Tcl_SetVar GLOBAL_ONLY

[<ke...@cr...>]

Brian,

You're certainly not doing anything wrong.  If the issue isn't a bug,
it's a misfeature.  It's hit me in the past; in fact, it's hit me so 
hard that I normally ignore the 'n1' parameter altogether.  Instead, 
I wind up establishing traces with

    trace add variable foo write \
        [list fooCallback [namespace which -variable foo]]

    proc fooCallback { realN1 n1 n2 op } {
        # ... realN1 has the fully qualified name.
    }

But even that is dangerous for arrays.  If someone 'upvar's an
array element:

    upvar #0 foo(bar) grill
    set grill {}

there is no trace callback at all.  For this reason, I find 'trace' to
be of real variable only for scalar variables, and I manage
collections either as lists or as namespaces.  This problem is
documented in Tcl Feature Request #572889.  In my opinion, it
renders whole-array traces completely useless.

One possible thing to help with the first problem (variable out
of scope) but not the second (aliased array element) would be to
qualify all non-local variables fully when firing the trace callback.
A similar change was recently made to 'trace add command' and
'trace add execution' for similar reasons.  The relevant code is
in CallCommandTraces in tclBasic.c - look for a call to
Tcl_GetCommandFullName.

My understanding is that the second misfeature is there, at least
in part, because of the first - the 'env' trace callback cannot
handle getting the local name under which an 'env' element was set.
It needs to know the key-value pair that was used.

Feh.

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
ke...@cr...           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA