Version 6 of atProcExit

Updated 2008-08-26 15:53:21 by lars_h

[TODO: describe (only NRE-wiki page of relevance appears to be [L1 ]); rename the command to something more tclish?] Consequence of NRE.

---

Lars H: A thought: how is this different from what can be had through the age-old technique of creating a dummy local variable and putting an unset trace on it? Basic implementation:

 proc atProcExit {script} {
    upvar 1 atProcExitScripts arr
    set arr($script) {}
    trace add variable arr($script) unset "$script\n\#"
 }

MS 2008-08-26 First please note that this is mostly exploiting the infrastructure of tailcall for a different and possibly interesting purpose, but is definitely the least thought-out of the new unsupported commands. It might not be more than a "tech show-off" for NRE.

Now to the actual question: some of the differences are:

• no need to find a variable name that is guaranteed not to be used, even in procs that may create and manipulate variables with names coming from the user
• the state of the interp when the script runs: with the var traces, the proc's internal structures are still occupying the Tcl stack, and some of the code is still using the C stack. These run when everything is really gone, just like tailcall would.
• well defined execution sequence (LIFO), which your construct does not guarantee (it is possible to have this feature with variable traces by putting the scripts in a list and running them in order within a [catch])

Lars H: OK, so mostly cleanliness differences. Executing when the proc is gone (tailcallishly) could actually be considered a disadvantage, because it is easy to imagine at-exit scripts wanting to access final values of variables; that trace scripts are not guaranteed to provide access to any specific variable either was actually what I feared might be the main shortcoming of the above proc! Could the NRE atProcExit be modified to run code after the proc body but before its local context is destroyed?

---