A rule of thumb for implementing a "Low Coupling Principle" for objects
[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/object-formulation.html]
[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/general-formulation.html].

"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[http://www.tcl.tk/cgi-bin/tct/tip/] 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. 

[Rohan Pall] '''2003-03-01''' The way I see it is that the more effective efficient tools the better.  I'm sure a smarty pants can come up with a way to use this thing very very effectively, without screwing up code architecture.  You can't just blanket statement a tool like this.  What's next on the hit list for code purists?

[escargo] I did not intend to say that the ''Law of Demeter'' puts features or practices on
a ''hit list'' of things that are forbidden. To the extent that using those features or practices
makes code more fragile, extra care is needed when coding them, documenting them, inspecting
them, and testing them.

[Rohan Pall] '''2003-03-01''' I don't agree that it makes code more fragile -- I do think in some cases it does, and in others it will actually work the other way --> helping your code architecture.  This doesn't change the fact that most people should stick to java where their screw ups cannot become extraordinary.  Ordinary tools for ordinary people, and extraordinary tools for extraordinary people.  Or something.  Then again I think forbidden fruit is extra crunchy.

ulis '''2003-03-02''' I agree with "Increased coupling makes code more fragile or more resistant to change" and "the more effective efficient tools the better". And I hate "code purists".

----
''Created by [escargo] on 28 Feb 2003''