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.)
Request notifications