Module naming conventions

[Bill Baxter]

For Kris's benefit --
My list below is intended to be a list of rationales that go beyond 
"just I like this, so it's better", to "it's better because of <some 
objective thing>".  So perhaps you will still say these are quibbles 
about style, but to me a style that is hard to use is objectively 
inferior.  Arguing about this_style vs ThisStyle from aesthetics alone 
is pointless, I agree.

Bill Baxter wrote:
> Stepping aside from the crazy Phango thread, I'd like to see if we can
> we try to put together a list of actual arguments for and against
> different module naming conventions.  No editorial comments by me here.
> 
> Is this list complete?
> 
> Convention LC: All package module names are lower case all the time.
> Example:   import foo.bar.baz;
> Pros:
> *) Long established convention (~10 years) used by Phobos

This isn't merely about style or personal preference for the reasons 
David Held so eloquently argued.  It's about playing nice and fitting in 
with the established rules of a community.

> *) Differentiates module names from class names.
>    Like class "Stream" in module "std.stream

Lack of differentiation can lead to confusion.  Is Util a class name or 
a module name?  If you're using uppercase modules it could be either.  I 
think this is only a real issue, though, when you have packages that are 
1-level deep.  In Tango you have tango.something always so you can tell 
by the initial "tango." that you're talking about a package, unless you 
end with two upper case things in a row, then it's a class.

> *) Related: prevents redundancy in fully qualified names
> (std.stream.Stream, not std.Stream.Stream)

It looks ugly but it also just looks wrong, so it's easy to forget that 
it's called std.Stream.Stream because the last name is repeated in a way 
that's unnatural.

> *) Easy-to-remember rule ("just use lowercase") prevents naming errors
> slipping through the cracks on case-agnostic Windows.

I've already said that I don't understand why this is a big deal , but 
it was the the reason brought up by Walter.  (And my paraphrasing above 
is not exactly what he said, but the only way I could make any kind of 
logical sense out of it.)

> Convention CC: All package names are lowercase, but module names are
> upper case, and match name of contained class where applicable.
> 
> *) Established convention (~4 years) used by Tango

Even though it's not the longest standing convention, it is a convention 
that's been around for a while.

> *) Differentiates package names from module names to prevent naming
> clashes. (Lets you have file "OpenGL.d" in same directory where there's
> an "opengl" package directory)

This is more than just preventing possible confusion to coders, it 
actually allows you to do something that would be impossible with all 
lower-case names.  So this differentiation actually gives you more 
freedom in how you organize your libraries.

> *) Makes it easy to remember name of module where class FooBar is
> defined (it'll be in FooBar.d)

Granted a similar convention for transformations to lower case could be 
devised, like FooBar --> foo_bar, but there's no transformation simpler 
than no transformation at all:  FooBar --> FooBar.

> *) Fine granularity approaching one-module-per-class means D's linker 
> will generate smaller executables.

D's linker (dmd only?) is not good at discarding parts of modules 
selectively.  So it's good to have small modules.  With classes, the 
smallest you can get is one class per file.  If you have one class per 
file, you're going to need to come up with a lot of module names.  Then 
we're back to the previous point.  Ignoring any other constraints, the 
obvious name to use is that of the class.


--bb