For some years I work on a Tcl driven cash register system now. It has grown
old and lot of cruft has cumulated. From time to time, I look for new stuff
in the Tcl codebase I could use to rework the application and throw out a
lot of things that has been neccessary in the past.
Now I stumbled over Tcl "dict"s, which seem to be a simple solution for a
lot of complicated code in my program. It has a lot of procs (and
remote-procedure) calls where list representations of arrays are used as
parameters.
proc some_proc {arr_list} {
foreach arr $arr_list {
unset -nocomplain arr_
array set arr_ $arr
...
puts $arr_(key1)
puts $arr_(key2)
puts $arr_(key3)
...
}
}
Could this be effectively replaced by dictionaries? I just tested it with
"puts [dict get $arr key1]" and it works. But I wonder if that is really
faster or even better than repacking the list into an array on every
iteration.
I also wonder why there is a "dict create" command when "list" does the
same. Any comments welcome.
Kind regards
Jan
I think it gets particularly interesting when you're working with
dicts of dicts, since then it's trivial to guarantee that the space of
keys at one level is distinct from the space of keys at another. I
always used to worry about the old style hack of putting array keys
together with commas: the case of a,b/c vs. a/b,c worried me (read the
'/' as separating two keys).
In terms of performance, doing lookups is about the same speed with
each, with more potential benefit if you're using multi-layer lookups
for reading. (There are some small unavoidable performance issues with
deep writes, but that's beyond what arrays can do anyway.) The real
benefit is that it is much easier to pass dicts by value; doing so
with arrays really sucks. There are a few other things you can do with
a dict if you're tricky, like sorting by key, which are impossible
with arrays.
> I also wonder why there is a "dict create" command when "list" does the
> same. Any comments welcome.
The [dict create] command will also do duplicate removal, though it's
really there for API completeness.
Donal.