The documentation for the [rename] command, used to rename Tcl procs, is available at http://purl.org/tcl/home/man/tcl8.5/TclCmd/rename.htm .
The [rename] command is most often used for wrapping commands. In other words, the programmer uses [rename] to hide another command -- so that a wrapper can be placed around the hidden command to change its behavior. Examples of this important concept abound on the Wiki; among the clearest are: DGP: Be aware that if you rename a command into another
[Discuss examples. Explain errorInfo subtleties (refer to live examples). Explain "return [eval ::_$original_command \$first_argument $args]" idiom.]
RS Another frequent application for rename is to remove commands, by renaming them to the empty string:
rename foo {}
DGP Be aware that if you [rename] a command into another namespace, its evaluation context will change to that namespace. HaO 2010-04-10: (discussion on CLT ): rename or delete from inside targeted proc is allowed:
% namespace eval one {
variable message "I'm in one"
proc test {} {variable message; return $message}
}
% namespace eval two {variable message "I'm in two"}
% rename one::test two::test
% two::test
I'm in twoGDE What's the recommended way to test for the pre-existence of the "destination" argument proc to avoid an error at runtime? The best I could come up with is:
if {![llength [info commands new_proc_name]]} {
rename old_proc_name new_proc_name
}MJ - The way to avoid the error is to use [catch], this is in line with the view that you shouldn't check if you can do something, but just do it (and handle errors):
if {[catch {rename old new}]} {
# handle error because new already exists
} GDE What if I actually do care about the error? In other words, I don't want to do the rename if I've already done it?
slebetman: No worries, rename won't let you do it and will generate an error. Use catch to prevent that error from halting your program and possibly do something if it happens (see MJ's example above).
(By way of context: this is in a script that may repeatedly get sourced into a single interpreter during a debug session. The first rename creates a backup of the "production" version of the proc then the rest of the script redefines a wrapper around that production version. The user may then edit the debug script to further refine the wrapper proc and re-source, but the catch method will then create a wrapper around the wrapper around the original, rather than just redefining the first wrapper.)
GDE Ahh, right, I've got it now - for some reason I thought the catch forced the operation, instead of failing "silently" (but detectably).
Tcl syntax help - Arts and crafts of Tcl-Tk programming - Category Command