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.

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.

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