CodeIsNotATree

One of the IsNotATree analogies with ACityIsNotATree.

A FrameWork is not a tree. But most IDEs come with a hierarchical class browser. Most try to cram class browsing into a generic "explorer" style tree-browser designed for a hierarchical file system. Yuck.

To get away from this, we need IDEs that provide hyperlinks between code. Ideally, we should be ProgrammingWithAndInWiki

In extreme cases, like Java, the package hierarchy is forcably mapped onto the file system hierarchy. And classes are stuck in deep tree structured namespaces. In contrast, recognizing code isn't a tree should lead us to the flat namespaces of wiki.

What would we lose in a flat namespace? The capacity to have multiple classes with the same name, but qualified by the organization that produced them. Here I'm reminded of JakobNielsen's point that your website shouldn't be structured like your company's org. chart? Why do external people care about your internal structure. Equally, why do programmers care about where a class comes from?

Q : But without qualified classnames, we wouldn't be able to have two classes with the same name!

A : Well, maybe that's not such a bad idea. How many times do you want two classes with the same name? Really? It's a nuisance.

Q : No, you don't want it. But sometimes it happens. What if you need to combine libraries from different suppliers, and they happen to come with the same name?

A : If we didn't support hierarchical name-spaces they wouldn't be able to. So we'd have to come up with some other solution. Like global(ish) agreements and registries.

Q : Huh? That would be chaos!

A : Works for internet domain names.

Q : You're a lunatic!

Phil (emerging from the anonymity of his A persona with a mad expression) : Also, as I mentioned in SemanticsOfProgrammingEnvironments, your understanding of the semantics of a name is fixed by a wider convention than just an arbitrary dictionary. So people shouldn't go round naming any class "ClassName". The string "ClassName" should be reserved for that library which ClassName roughly fits.

Q : You don't really believe that, do you?

Phil : hmmmm. Maybe the DevilIsInTheDetails

ps : of course, code is a tree. Deep down it's really an AbstractSyntaxTree :-)

(See also JackPot)