Tcl Source Code

View Ticket
Login
Ticket UUID: ace7bf3dcff30d649961bcabd4caea48a1ac0b49
Title: trace on upvar'd arrays appears inconsistent
Type: Patch Version: 8.6
Submitter: cmcc Created on: 2014-05-25 21:52:17
Subsystem: 46. Traces Assigned To: nobody
Priority: 5 Medium Severity: Minor
Status: Open Last Modified: 2014-05-26 13:27:11
Resolution: None Closed By: nobody
    Closed on:
Description:
Per the code below, I would have expected the upvar'd element modification to trigger the array trace as well as the element trace.  I accept that this may be a lot of work and complexity for what is a corner case.  I suggest that the documentation specify the behaviour in this case.

variable V; array set V {}

proc eincr {} {
    upvar #0 V(a) a
    incr a
}

proc aincr {} {
    upvar #0 V V
    incr V(a)
}

proc varmod {args} {
    puts stderr "varmod: $args"
}

::trace add variable V(a) {write unset} [list varmod element]
::trace add variable V {write unset} [list varmod array]

puts stderr "global set"
set V(a) 1	;# triggers array and element traces

puts stderr "upvar array element set"
aincr		;# triggers array and element traces

puts stderr "upvar element set"
eincr		;# triggers only element trace
User Comments: msofer added on 2014-05-26 13:27:11:
It is a dup in my mind, as they require the same changes to fix AND we would want to keep things consistent anyway.

The problem is that array elements do not know which array they belong to - in order to solve this we would have to expand the Var struct, or else treat links to array elements differently.

dgp added on 2014-05-26 13:09:51:
Not quite a Dup, I guess, since one is about read and 
the other about write traces, but I bet a common patch
could take care of both.

Note the doc excerpt in the other ticket, that this
behavior, though unwelcome, is apparently documented.
It *may* be connected to (earlier?) implementations of
::env variable maintenance.

dgp added on 2014-05-26 13:03:57:
How does this relate to

http://core.tcl.tk/tcl/tktview?name=572889

?