A rule of thumb for implementing a "Low Coupling Principle" for objects [L1 ] [L2 ].
"The Law of Demeter was originally formulated as a style rule for designing object-oriented systems. "Only talk to your immediate friends" is the motto. The style rule was discovered at Northeastern University in the fall of 1987 by Ian Holland.
A more general formulation of the Law of Demeter is: Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Or: Each unit should only talk to its friends; Don't talk to strangers."
What has this got to do with tcl?
Consider lset or some of the extra features proposed for various new or enhanced commands, for example recent TIPs[L3 ] TIP 111 and TIP 127.
By allowing access to the extra depth into nested lists or dictionaries, coupling is increased.
It's a trade off between increased coupling between the code and the data and increased performance.
Increased coupling makes code more fragile or more resistant to change.
This not to say that tcl should not allow such deep indexing, but people should be clear on the consequences.
NEM 1Mar2003 - While this sounds good in principle, I fail to see how allowing multiple indices (essentially giving multiple dimension lists), and adding a new dictionary data type could in any way be a bad thing. Admittedly, if you have two indices into a list, then more can go wrong if the structure of the list changes, but I don't really consider that too much of a problem. Most times I would use more than one index would be where it made sense (for instance representing a grid in a list), so the list structure is unlikely to change. As for adding the new dictionary data type, you've completely lost me here - in what way does this increase coupling between objects?
escargo - The problem (such as it is) is that when you start having nested structures your code has to make assumptions about the kind of objects it's dealing with. For example, a straight lindex will index into any list. An lset with multiple indices makes assumptions beyond each element being a simple list. (Likewise, indexing into a dictionary is straightforward, but indexing into what is supposed to be a dictionary of dictionaries makes an additional assumption.)
So, how can you easily verify that a list is composed of elements that are all two-element lists? (So that lset will do what you want, or the proposed changes to lsearch.) To the extent that assumptions might be incorrect and the code might not be robust in the presence of unmet assumptions there might be problems.
Michael Schlenker 2Mar2003 - I agree with escargo, that nested structures raise the fragility of code significantly, but what is the alternative? Path one: use a C-coded extension for all complex data structures and manipulation of them. This is the old tcl way as envisioned by Ousterhout, as far as i have read the papers. Path two: use an OO-framework for more complex data. I use this with XOTcl, but like the simplicity of nested lists.
Take a look at the struct module of tcllib. It grows and grows and grows, why? Programmers want extra data structures without using any C-extension or the burden of OO. Giving them tools to build such structures from nested lists or dictionaries is o.k. in my point of view.
Basically the only problem is missing list introspection, nothing more and nothing less. And there is no simple way to fix it, as a list is just a strong shadow behind the string representation.
Created by escargo on 28 Feb 2003