From: SourceForge.net <no...@so...> - 2013-01-02 20:12:20
|
Bugs item #3599017, was opened at 2012-12-31 08:19 Message generated for change (Comment added) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3599017&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: 46. Traces Group: current: 8.6.0 >Status: Pending >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Poor Yorick (pooryorick) Assigned to: Don Porter (dgp) Summary: trace that unsets and then sets and array Initial Comment: In the following example, the asnwer to [info exists ::var1] is "1", but the answer to [info exists var2(1)] is "0". Is this not inconsistent? set ::var1 [list 1 v1] trace add variable ::var1 {read} ::trace1 proc trace1 { args } { unset ::var1 set ::var1 [list 1 v1] } puts [info exists ::var1] array set ::var2 [list 1 v1] trace add variable ::var2 {read} ::trace2 proc trace2 { args } { array unset ::var2 array set ::var2 [list 1 v1] } puts [info exists ::var2(1)] ---------------------------------------------------------------------- >Comment By: Don Porter (dgp) Date: 2013-01-02 12:12 Message: The same "inconsistency" is present back in Tcl 7.6. Whatever might arguably be "right", the stable choice is not to mess with this in the Tcl 8 time frame. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2013-01-02 12:04 Message: The problem is not just consistency, but how that consistency came to be, whether by intent or accident, and what code out there relies on current behavior (think Tk). That said, it might be interesting to see what happens if TclVarTraceExists() makes another TclLookupVar() call after traces complete. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3599017&group_id=10894 |