A suggestion for modules names / sharing code between projects

[Mike Parker via Digitalmars-d]

On Wednesday, 2 March 2016 at 06:40:53 UTC, Sebastien Alaiwan 
wrote:

> Yeah, this is what I going to do: flat hierarchy, like one 
> 'src' directory and one 'extra' directory in the project root, 
> globally unique package names, passing -Isrc and -Iextra to the 
> compiler, and ... module declaration directives.
> I was trying to avoid them, but maybe it's not possible.

Every module you create will have a module name whether you use a 
module declaration or not. If you don't use one, the compiler 
uses the file name by default, but *only* the file name. The path 
on the file system is in no way taken into account (I suppose it 
could be by adding a flag to the compiler, but it seems to me 
that would needlessly complicate what is a really simple and easy 
to use system). A module with no package name is in the default 
package, i.e. given src/foo.d, using the following declaration:

module foo;

Is the same as using none at all. If you are content with keeping 
all of your modules in one or more top-level directory and use no 
packages, then you can leave out the module declarations and just 
pass each top-level directory to the compiler with -I.

>
> I still think that software entities shouldn't depend upon 
> their own name, or their absolute location in the top-level 
> namespace.
>
> This is true for classes, functions/methods, variables, 
> structures ... maybe this rule becomes invalid when third-party 
> packages enter a project?

The module names and package names are mangled into the symbol 
names in the binary. They also serve as namespaces to distinguish 
conflicting symbols in code. So yes, all of the symbols in a 
module are dependent on their location in the namespace. It's 
baked into the language.

I'm curious what sort of system you have in mind. How does the 
current system not work for you and what would you prefer to see?