PWQ 29/01/04
With a casual look through the code, there seems to be at first glance only a small amount of effort to give access to dict types using the array notation.
What some people desire is the following:
set fred [dict create A 1 B 2]
puts "B = $fred(B)"
puts "fred is a $fred"While there are pro's and cons to both sides for and against. It could only be a good thing if variables,lists,arrays, and now dicts interoperate as much as possible to limit the number of ways data is accessed.
One option would be to deprecate the use of $var which would be one way to reduce the number of different data access methods, by enforcing the use of [type get] notation for all.
Assuming the above is not a contender, then another simple change would be to modify Tcl_GetVar2 and cousins.
At the moment if a reference in the form of $name(element) finds that name is a scaler, then an error is thrown. It would be simple at this point to add a test to see if the scaler is of type DICTIONARY. The code can then fall through to return Tcl_DictGet (or similar).
I suspect the in the Byte compiler it is not that simple, my comment would be Too freaking bad. Any complications caused by the BC should NOT be used as arguments against evolution of the language.
If we were to accept the above is trivial and feasible, and apply proactive design methodologies (rather then the normal reactive ones the TCT uses), we would at this point replace the test for DICTIONARY with instead an installable subsystem that could implement more than just dictionaries, and only add a few extra commands to the tcl core in the process.
Before embarking on a discussion of the above, one should first determine the frame of reference for what the considerations should be. For example:
My evaluation of the above, shows that the pro's significantly outway the cons.
I could at this point extend the changes to include such things as array shadowing, persistant stores, but I am sure the above is contentious enough to ensure a resounding NO.