Module naming conventions

[Jari-Matti Mäkelä]

Steven Schveighoffer wrote:

> "Bill Baxter" wrote
>>> *) 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.)
> 
> Here is why it's a deal (maybe not big, perhaps melon-sized):
> 
> import tango.io.XmlFile
> import tango.io.XMLFile
> 
> (note these are not real modules)
> 
> I intuitively use the second version, because it looks weird to me when
> you
> change the case of an acronym.  But some people may intuitively use the
> first.
> 
> So let's say for argument's sake that XmlFile.d is the real version.  If
> I'm developing my application on windows, and my pre-programmed fingers
> type
> 'XMLFile', it compiles, without me realizing that the case is wrong.  When
> I try porting to Linux, I now get an error because XMLFile.d doesn't
> exist, it's XmlFile.d.
> 
> See, the problem with CamelCase is that it is sometimes subjective as to
> what part of the name should be capitalized.  This in itself isn't a huge
> problem except that on case-insensitive file systems, it is possible for
> the program to compile even though it shouldn't.

Image code where there's a module & class for LaTeX files. So you can have
at least 16 possibilities: { latexfile, latex_file, LatexFile, LaTeXFile }
choices for both, the class and the module. Of course you could also use
class CFoo {} style or write all in caps. What we need is a preprocessor!
It would also solve another issue, I've always wanted to begin my programs
with 'BEGIN' and end with 'END.' jk :P