Phango

[Oskar Linde]

It is interesting to see how such a trivial thing as the capitalization 
of module names can lead to a much more involved discussion than any of 
Tango's technical merits ever have (possibly with one exception). It is 
somewhat like making a choice between two equipment manufacturers from 
the colors they use on the buttons. But form and style seems to be of 
undervalued importance, and maybe there is more to this issue than it 
appears. Either way, I cannot refrain from writing something about it 
too. :)

Lars Ivar Igesund wrote:

> Using fully qualified class names are very seldom necessary in D, I find
> using renaming imports are much more useful. I'd like to turn your argument
> the other way round: If you do
> 
> import package.Foo;
> 
> then it make a lot of sense that you can just use your class Foo. 

What says that the module package.Foo contains a class named Foo? Most 
of my own modules contain no classes at all, and many that do contain 
more than one class. I know that (with different qualifiers), that is 
true for Tango as well.

I wouldn't encourage module renaming, at least not without guidelines 
for how things should be renamed. Lots of people making up their own 
custom abbreviations for the same long module names can't lead to 
something good.

I am personally quite fond of using FQN (fully qualified names) in 
certain situations, but names such as

tango.util.collection.iterator.InterleavingIterator.InterleavingIterator

make that a tad inconvenient. :)

Three design choices in Tango seem to be:

* deep rather than shallow package hierarchy
* descriptive rather than abbreviated package names
* highly fragmented modules

In some ways, I tend to feel those three points are misdirected, or at 
least taken a bit too far.

What are the reasons for dividing things into modules? First and 
foremost, functionally independent parts should be separated so that one 
can be replaced or used independent of the others. Secondly, there are 
some issues with compile times and object file sizes, and the third 
reason is convenience for the implementors. The reasons mentioned are in 
descending order of importance. A library should always be designed for 
its users, rather than for its implementers.

We humans, psychologically, tend not to be very hierarchical in our 
categorization of the world. There is a basic level of categorization 
that is the one most readily named and first learned (bird, cat, car). 
The function of a categorization should be to provide the maximum amount 
of information with the least amount of cognitive effort. The more fine 
grained a categorization is, the more cognitive effort is needed. The 
conclusion is that it would be cognitively advantageous to only separate 
library entities into different modules if there is a relevant reason to 
do so (for the purposes at hand).

I believe shallow hierarchies generally are better than deep, and also 
that there should be a functional rather than logical separation between 
packages.

So, instead of:

tango.util.collection.iterator.InterleavingIterator

couldn't there just be:

tango.collection.iterators

or perhaps even:

tango.collection

An interesting parallel is the taxonomy of plants and animals from the 
18th century. The Linnaean taxonomy is a highly hierarchical 
classification, where for instance the common snowdrop is classified as:

Plantae.Magnoliophyta.Liliopsida.Asparagales.Amaryllidaceae. 
Galanthus.nivalis

But such names were considered too unwieldy to use in full, so a concise 
binomial nomenclature was used as a supplement. The same snowdrop as 
above in binomials is just:

Galanthus.nivalis

Regarding capitalized module names: As far as I see it, there are 
entities (functions, classes, etc) and modules (std.string, 
tango.text.convert.Format). I don't really see the point of making a 
distinction between modules and packages, and therefore can't really see 
a point in capitalizing the last part of the module name only. But on 
the other hand, there is a precedent in the binomials above -- only the 
other way around. :)

> I could of course also pull in Java and C# as examples, but those are
> weirdly enough disregarded in this debate.

Not so weird for Java at least (I don't know C# well enough to comment). 
Java (more or less) forces file names to be identical to the sole public 
class in them. There are no modules in java, just classes, and since 
classes are capitalized, so are the file names.

To end, I think it speaks very highly of Tango that the only issues 
being actively debated are the purely stylistic ones.

-- 
Oskar