www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Module naming conventions

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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 cancelled the original message to update with Sean's comment about 
linker granularity.]
Nov 18 2007
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Bill Baxter Wrote:


 *) Long established convention (~10 years) used by Phobos


About 6 years (2001), I think.


 *) Established convention (~4 years) used by Tango


Less than 1 year. Ares was around before (3 years ago, according to dsource),
and also used camel case.


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


Can you elaborate on this one so I don't have to read the whole Phango thread?
Why is this true? And there can still be one-class-per-module (what's
one-module-per-class? A typo or am I misunderstanding something?) even with a
lower-case module naming convention, so that's not really an argument for camel
case.
Nov 18 2007
next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Robert Fraser wrote:

 Bill Baxter Wrote:

 *) Established convention (~4 years) used by Tango


 
 Less than 1 year. Ares was around before (3 years ago, according to dsource),
and also used camel case.


A large portion of Tango has been migrated from Mango, which used pretty 
much the same convention.


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Nov 18 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Robert Fraser wrote:

 Bill Baxter Wrote:
 

 *) Long established convention (~10 years) used by Phobos


 
 About 6 years (2001), I think.
 

 *) Established convention (~4 years) used by Tango


 
 Less than 1 year. Ares was around before (3 years ago, according to dsource),
and also used camel case.


Actually, it didn't.  The CamelCase came to Tango from Mango, which was 
started perhaps 4 years ago by Kris.  Ares followed the Phobos style 
guidelines.


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


 
 Can you elaborate on this one so I don't have to read the whole Phango thread?
Why is this true? And there can still be one-class-per-module (what's
one-module-per-class? A typo or am I misunderstanding something?) even with a
lower-case module naming convention, so that's not really an argument for camel
case.


I think this may be a separate issue.  I was describing why Tango has so 
darn many modules, which I believe came up as a general stylistic 
difference between Phobos and Tango.


Sean
Nov 18 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 Robert Fraser wrote:

 Bill Baxter Wrote:


 *) Long established convention (~10 years) used by Phobos


 About 6 years (2001), I think.


 *) Established convention (~4 years) used by Tango


 Less than 1 year. Ares was around before (3 years ago, according to 
 dsource), and also used camel case.


 
 Actually, it didn't.  The CamelCase came to Tango from Mango, which was 
 started perhaps 4 years ago by Kris.  Ares followed the Phobos style 
 guidelines.
 

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


 Can you elaborate on this one so I don't have to read the whole Phango 
 thread? Why is this true? And there can still be one-class-per-module 
 (what's one-module-per-class? A typo or am I misunderstanding 
 something?) even with a lower-case module naming convention, so that's 
 not really an argument for camel case.


 
 I think this may be a separate issue.  I was describing why Tango has so 
 darn many modules, which I believe came up as a general stylistic 
 difference between Phobos and Tango.


Different maybe, but there's a logical chain of implications there.

If it's good for the linker to have fine granularity modules, then it 
makes sense to put each class in its own file (when there are classes). 
  If you're going to have lots of modules with only one class, then it 
makes sense to name the modules after the class contained in some way. 
Then if module names are going to a variation on class names, you might 
as well make them exactly the same.

Though for lowercasing, I suppose you could just use a different 
convention, like put class PenIsland in module pen_island.

Put in the negative, you might say the looser convention of names like 
"std.stdio" doesn't mesh well with the current capabilities of the DMD 
linker.

--bb
Nov 18 2007
prev sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:


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


 
 Can you elaborate on this one so I don't have to read the whole Phango thread?
Why is this true? And there can still be one-class-per-module (what's
one-module-per-class? A typo or am I misunderstanding something?) even with a
lower-case module naming convention, so that's not really an argument for camel
case.


Sure.  Sean Kelly wrote:
"""
I'll admit that I find this [module name to class name] correspondence 
most useful when dealing with Tango's IO package however, because it is 
so heavily modular.  In fact, this modularity is the reason there are 
few aggregate modules.  Tango is designed in a manner that largely 
avoids unused code being linked into an application by spreading it 
across multiple modules.  One may argue that block-level linking would 
mostly solve this problem as well, but it currently does not work with 
D, and things like static data, module ctors, etc, would not be omitted 
even with this feature.
"""

--bb
Nov 18 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Nov 18 2007
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"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.

If all module names are lower case, then this doesn't happen.  I know that I 
have to lower the case of everything, even acronyms.  There is no 
subjectivity.

Is this a big deal?  Not really.  Back to my example, if I'm porting to 
Linux, I see the problem from the compiler, then I fix my files (probably 
with a search/replace script), and I'm done.  In the code, even on Windows, 
I'm not able to compile if I use the *class name* XMLFile, so the only part 
that doesn't work is the import.

So there's reason for wanting lower case, and reason for wanting CamelCase. 
I don't think either is right or wrong, or that either reasoning far 
outweighs the other.

-Steve
Nov 19 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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)
 [good explanation snipped]

 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.

 If all module names are lower case, then this doesn't happen.  I know that I 
 have to lower the case of everything, even acronyms.  There is no 
 subjectivity.


Yeh, if you convert to lower case improperly -- by adding extra 
underscores (std.out_of_memory), or otherwise mangling incorrectly, 
(std.regex, std.signals) -- then you will certainly get a compiler error.

But I think Don's point is still valid.  Why doesn't the compiler check 
the module declaration on Windows?  If you import tango.io.XMLFile and 
the file the compiler gets from the OS has a module declaration saying 
"module tango.io.XmlFile", then the compiler should barf on that.


 Is this a big deal?  Not really.  Back to my example, if I'm porting to 
 Linux, I see the problem from the compiler, then I fix my files (probably 
 with a search/replace script), and I'm done.  In the code, even on Windows, 
 I'm not able to compile if I use the *class name* XMLFile, so the only part 
 that doesn't work is the import.


--bb
Nov 19 2007
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote

 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)
 [good explanation snipped]

 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.

 If all module names are lower case, then this doesn't happen.  I know 
 that I have to lower the case of everything, even acronyms.  There is no 
 subjectivity.


 Yeh, if you convert to lower case improperly -- by adding extra 
 underscores (std.out_of_memory), or otherwise mangling incorrectly, 
 (std.regex, std.signals) -- then you will certainly get a compiler error.

 But I think Don's point is still valid.  Why doesn't the compiler check 
 the module declaration on Windows?  If you import tango.io.XMLFile and the 
 file the compiler gets from the OS has a module declaration saying "module 
 tango.io.XmlFile", then the compiler should barf on that.


I like this idea, but of course, there would have to be a requirement for 
module names to match the file names (which is not the case today).  I think 
this really is one of the parts of D that could use some improvement.

-Steve
Nov 19 2007
prev sibling parent Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
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
Nov 19 2007
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.


You've left out free functions.

FWIW,
The CC convention
*) Differentiates module names from function names.
Nov 19 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Don Clugston wrote:

 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.


 
 You've left out free functions.
 
 FWIW,
 The CC convention
 *) Differentiates module names from function names.


Thanks.  Missed that one.  That's the parallel of the "Differentiates 
module names from classes" of the LC convention.

But really, the names of modules and functions aren't very likely to be 
similar to begin with.  Probably why you tagged it FWIW?

--bb
Nov 19 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 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.


This is not a big issue, but an irritation: sometimes, I see code 
developed on windows that names a file like: "Foo.h", but then 
#include's it with "foo.h". It all works fine until one tries to port 
the code to Linux. Worse, sometimes you'll see the reverse problem, 
where there's a Foo.c and a foo.c on Linux and you have to port it to 
windows.
Having all file/module/package names in lower case is just a no-brainer 
way to avoid this issue.

I'll also confess I just don't like filenames with caps, underscores, or 
special characters in them, nor do I like long filenames. I have some 
image programs that insist on writing out .JPG files, and if I forget to 
rename them to .jpg before ftp'ing them to the web server, they don't 
work. Using all lower case, simple filenames, minimizes problems moving 
the files between systems.

I'm surprised nobody has asked why D doesn't simply enforce module names 
to be in all lower case <g>. The answer is the language shouldn't 
enforce stylistic issues, it would be as if { } style were enforced. 
Many people are turned off from Python because it enforces an indenting 
style.
Nov 19 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 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.


 
 This is not a big issue, but an irritation: sometimes, I see code 
 developed on windows that names a file like: "Foo.h", but then 
 #include's it with "foo.h". It all works fine until one tries to port 
 the code to Linux. Worse, sometimes you'll see the reverse problem, 
 where there's a Foo.c and a foo.c on Linux and you have to port it to 
 windows.
 Having all file/module/package names in lower case is just a no-brainer 
 way to avoid this issue.
 
 I'll also confess I just don't like filenames with caps, underscores, or 
 special characters in them, nor do I like long filenames. I have some 
 image programs that insist on writing out .JPG files, and if I forget to 
 rename them to .jpg before ftp'ing them to the web server, they don't 
 work. Using all lower case, simple filenames, minimizes problems moving 
 the files between systems.
 
 I'm surprised nobody has asked why D doesn't simply enforce module names 
 to be in all lower case <g>. 


You could prohibit the use of module names differing only in case.

So that if one module has
import foo.bar;
and another has
import foo.Bar;
an error should be generated, even if the file(s) would be found on that OS.
The correct capitalisation should be obtained from the module statement.
(And even on Windows, you _could_ still check to see if the file case matches 
the module statement).
Nov 19 2007
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Don Clugston wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 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.


 This is not a big issue, but an irritation: sometimes, I see code 
 developed on windows that names a file like: "Foo.h", but then 
 #include's it with "foo.h". It all works fine until one tries to port 
 the code to Linux. Worse, sometimes you'll see the reverse problem, 
 where there's a Foo.c and a foo.c on Linux and you have to port it to 
 windows.
 Having all file/module/package names in lower case is just a 
 no-brainer way to avoid this issue.

 I'll also confess I just don't like filenames with caps, underscores, 
 or special characters in them, nor do I like long filenames. I have 
 some image programs that insist on writing out .JPG files, and if I 
 forget to rename them to .jpg before ftp'ing them to the web server, 
 they don't work. Using all lower case, simple filenames, minimizes 
 problems moving the files between systems.

 I'm surprised nobody has asked why D doesn't simply enforce module 
 names to be in all lower case <g>. 


 
 You could prohibit the use of module names differing only in case.
 
 So that if one module has
 import foo.bar;
 and another has
 import foo.Bar;
 an error should be generated, even if the file(s) would be found on that 
 OS.
 The correct capitalisation should be obtained from the module statement.
 (And even on Windows, you _could_ still check to see if the file case 
 matches the module statement).


Taking the opposite approach -- explicitly ignoring capitalization, even 
if the filesystem in case sensitive -- will eliminate discussions of 
this nature, on the other hand, will strongly encourage people using 
case-sensitive filesystems to not have modules whose names differ only 
in case, and will probably take less code than your recommendation.

I don't see either one happening in the near future, though.
Nov 19 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Don Clugston wrote:

 (And even on Windows, you _could_ still check to see if the file case 
 matches the module statement).


One of the reasons for the module statement is if the file name needs to 
differ for some reason.
Nov 19 2007
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Don Clugston wrote:

 (And even on Windows, you _could_ still check to see if the file case 
 matches the module statement).


 
 One of the reasons for the module statement is if the file name needs to 
 differ for some reason.


I've run into one case where this is important, and can conceive of 
others.  And while it may be nice if the compiler simply verified case, 
doing only that seems rather arbitrary.


Sean
Nov 19 2007
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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?
Nov 19 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Christopher Wright wrote:

 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?


Agreed.  I'm realizing that it was wrong to ignore the distinction.

I think ultimately it may comes down to lowercase making the most sense 
for flat hierarchies with big modules, and camel case making the most 
sense for the hierarchies with many small modules.  So in that sense 
both Phobos and Tango use the convention that works best with the 
overall library organization.

--bb
Nov 19 2007
parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 
 I think ultimately it may comes down to lowercase making the most sense 
 for flat hierarchies with big modules, and camel case making the most 
 sense for the hierarchies with many small modules.  So in that sense 
 both Phobos and Tango use the convention that works best with the 
 overall library organization.


Good point.


Sean
Nov 19 2007
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
clrly th nly snsbl nmng cnvntn s nx: n cps r vwls

  - grgr rchrds
Nov 19 2007
next sibling parent Regan Heath <regan netmail.co.nz> writes:
Gregor Richards wrote:

 clrly th nly snsbl nmng cnvntn s nx: n cps r vwls


clrly nt!
Nov 19 2007
prev sibling parent reply "Kris" <foo bar.com> writes:
"Gregor Richards" <Richards codu.org> wrote in message 
news:fhsgpt$2j4f$1 digitalmars.com...

 clrly th nly snsbl nmng cnvntn s nx: n cps r vwls

  - grgr rchrds


Awesome idea! How about "Tango 0.99.4 GoBblYDeEeeeGooK rEllleeEEeeSsS", 
where all module names and symbols will be renamed accordingly?

Vote ++ for The Gregor today!
Nov 19 2007
parent Gregor Richards <Richards codu.org> writes:
Kris wrote:

 "Gregor Richards" <Richards codu.org> wrote in message 
 news:fhsgpt$2j4f$1 digitalmars.com...

 clrly th nly snsbl nmng cnvntn s nx: n cps r vwls

  - grgr rchrds


 
 Awesome idea! How about "Tango 0.99.4 GoBblYDeEeeeGooK rEllleeEEeeSsS", 
 where all module names and symbols will be renamed accordingly?
 
 Vote ++ for The Gregor today! 
 
 


If you name it GOBBLE-deegook you can release it on Thanksgiving.

  - Gregor Richards
Nov 19 2007