Module naming conventions

[Christopher Wright]

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
> 
> *) Differentiates module names from class names.
>    Like class "Stream" in module "std.stream
> 
> *) Related: prevents redundancy in fully qualified names
> (std.stream.Stream, not std.Stream.Stream)
> 
> *) Easy-to-remember rule ("just use lowercase") prevents naming errors
> slipping through the cracks on case-agnostic Windows.
> 
> 
> 
> 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
> 
> *) 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)
> 
> *) Makes it easy to remember name of module where class FooBar is
> defined (it'll be in FooBar.d)
> 
> *) Fine granularity approaching one-module-per-class means D's linker 
> will generate smaller executables.

I thought there was overhead for each module, and a good linker 
shouldn't lump in everything from every referenced module. So this point 
is not clear to me.

Also, there are two orthogonal issues here: having small modules and 
having CamelCase modules. Can we discuss them separately?