Package-Module-Import style guide

[Jarrett Billingsley]

"Todd" <toddtitus at mindspring.com> wrote in message 
news:fe5pve$jke$1 at digitalmars.com...
> Ok,
> Now that I have gotten myself buried under the 'package and module have 
> same name'  boulder, what is the latest word on how to layout packages and 
> modules? The more I read through, the more my head hurts. I haven't found 
> the 'Module' section yet, is it archived somewhere?

The module section of the spec?  You mean the part of the spec called 
"Modules", right after "Lexical"?

But anyway, the convention is to do something like this: you have your 
package, let's call it "fork".  fork has several modules in it, and maybe 
even other packages.  If you want to import all the modules (or just those 
which are useful to external programs) from fork, usually you'll provide a 
fork.all module which *publically* imports all the other needed modules from 
fork, like:

module fork.all;

public
{
    import fork.knife;
    import fork.spoon;
    import fork.spatula;
}

Then your other code just imports "fork.all" and it gets everything it 
needs.

That's about the only real convention.  The spec says as far as naming goes, 
package and module names should be all lower-case to avoid problems between 
case-sensitive and -insensitive file systems, but the only time such an 
issue might arise is if you were to name two modules names that differed 
only by case (like fork.spoon and fork.Spoon) on a case-sensitive file 
system, and then moved them to a case-insensitive file system.  So, for 
example, Tango has all its package names as lowercase, and all its module 
names as CamelCase.  Basically as long as you stick to a consistent naming 
scheme, and always refer to modules exactly how they're named, you shouldn't 
have issues.