Forum OpenACS Q&A: Response to "good" tcl code

Collapse
Posted by Tom Jackson on

empty_string_p isn't that bad. It seems like anytime you can condense even a few statements into one simple proc, it is worth it in readability of your code. But occasionally I wonder if empty_string_p is available, and I use instead:

string match "" $string

Which seems pretty easy to understand all by itself.

Collapse
Posted by Andrew Piskorski on
The empty_string_p proc was certainly a pretty good idea at the time it was created - remember, that was a long time ago, back in some really old Tcl 7.x version. If I remember correctly, the implementation of empty_string_p was changed several times over the years to take advantage of changes and improvements in the Tcl core. And the oft seen {$foo = ""} alternative, was never the right code to use, as others have pointed out above.

The proc should, however, have been named empty_p - the 7 extra characters of "_string" are unnecessary and undesirable in such a basic function that is used so frequently.

Now that the "string equal" command exists, there would probably be no good reason to create an empty_string_p proc if starting over from scratch today. (The "string match" command is doing something more general and complicated and is thus a poorer choice.)

As for performance, note that in the unlikely even that it turned out to be a performance bottleneck, AFAIK, it would be entirely plausible to add an empty_string_p bytecode command to the Tcl interpretor, which would make empty_string_p absolutely as fast as possible. I'm not sure though whether you could do that just by loading in some C code with "package require", or if it would mean hacking the Tcl core. (And unfortunately, standard Tcl does not have a macro facility to let you do that sort of performance tweaking at a higher level without hacking C code.)