At 07:03 PM 1/19/05 -0500, Timothy Fitz wrote:

On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne wrote:

...

"Flat is better than nested" has one foot in concise powerful programming, the other foot in optimisation.

foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable lookup.

I find it amazingly hard to believe that this is implying optimization over functionality or clarity. There has to be another reason, yet I can't think of any.

Actually, this is one of those rare cases where optimization and clarity go hand in hand. Human brains just don't handle nesting that well. It's easy to visualize two levels of nested structure, but three is a stretch unless you can abstract at least one of the layers. For example, I can remember 'peak.binding.attributes' because the 'peak' is the same for all the packages in PEAK. I can also handle 'peak.binding.tests.test_foo' because 'tests' is also always the same. But that's pretty much the limit of my mental stack, which is why PEAK's namespaces are organized so that APIs are normally accessed as 'binding.doSomething' or 'naming.fooBar', instead of requiring people to type 'peak.binding.attributes.doSomething'. Clearly Java developers have this brain-stack issue as well, in that you usually see Java imports set up to have a flat namespace within the given module... er, class. You don't often see people creating org.apache.jakarta.foo.bar.Baz instances in their method bodies.