On packages and naming them

[Bill Baxter]

This was going to be a proposal, but then I realized that D actually 
already has a nice way to deal with the issue.  So consider this an 
essay about how to use packages effectively in D.  Hopefully someone 
will find it informative.

Problem:
D code tends to work best when placed in a package [1], but a good 
package name is not always obvious.  I observe a few of strategies in use:

[Strategy 1] Just use a generic name like "utils" or "tools".  This 
makes the D compiler happy, but only until someone else decides to name 
their package the same thing.

[Strategy 2] Just use a random made-up name, like "cashew", "schooner", 
"tango", or "derelict".  This is fine except these packages often become 
huge, containing lots of disparate libraries and no one user is likely 
to want them all.  For instance a dev might want cashew.utils.Array but 
couldn't care less about cashew.cgi.*.  The granularity is bad.  You end 
up with a lib that is a monolithic assortment of eclectic rubbish.

[Stragegy 3] (from Java) Put modules inside net-derived package names 
like "com.sun.java".  That eliminates clashes but it's just ugly. 
Chances are there's only going to be *one* SWT out there, so saying 
"org.eclipse.swt" every time you import an SWT module is a little 
tedious.  And sometimes affiliations change, companies get acquired, or 
you're just a hobby dev and don't actually *have* your own domain name 
to use.

[Strategy 4] For an individual developer, use your initials or some form 
of your name.  This is ok if you intend to make this project "yours" 
forever, but if you're starting an open source project, I think putting 
any form of your own name on it is a bad practice.  It discourages 
others from joining the project.  Plus it has similarities to Strategy 
2, in that your name has nothing to do with the contents of the package, 
so the contents will end up being a random grab-bag.

POSSIBLE REMEDIES:

Here I was about to propose a few new ways to handle this, but realized 
that one of my proposals is actually possible, and indeed already in 
use.  So I'll just point out the solution:

The idea is just to split a single package across multiple locations. 
This is actually possible now, and is in fact used by Derelict to 
organize its various sub-projects.

So this means you can happily use a random-name package (Strategy 2) for 
everything you do without forcing everyone who uses one part of that 
package to download/install all of it.

If you use dsss for building/distribution you need to specify different 
names for the different components, but it's straightforward, just see 
derelict/DerelictAL/dsss.conf for instance. 
(http://www.dsource.org/projects/derelict/browser/trunk/DerelictAL/dsss.conf)

Still I think maybe D and supporting tools could do more to support this 
very nice paradigm.  For instance the Derelict source tree is kind of a 
mess because all the separate sub-libraries are in sub-directories.  So 
there is much redundancy in the directory layout: 
derelictFoo/derelict/foo/Foo.d, derelictBar/derelict/bar/Bar.d
It would be nicer if the derelict source tree could just be under a 
single top-level derelict/ directory.  There are probably issues with 
SVN involved there too in the decision to organize that way.

So I'm not sure what could be done to make that easier.

However there is one thing that I think D could do to make using 
pacakges easier, and that is

   Package aliases

But I think I'll put it in a separate message because it switches gears 
from an essay on how to do things now, to a proposal for a change.



[1] As an example I recently ran into a conflict where my module called 
just "memory" clashed with a module in Tango called 
"tango.something.something.memory".  So a package-less module can clash 
even with a deeply nested module in a package.  There are troubles with 
installation, too, (with DSSS) since all package-less modules are copied 
to the same DSSS include directory.

--bb