A suggestion for modules names / sharing code between projects

[ag0aep6g via Digitalmars-d]

On 02.03.2016 21:40, Sebastien Alaiwan wrote:
> - I only work with separate compilation, using gdc (Windows-dmd produces
> OMF, which is a dealbreaker ; but I use rdmd a lot for small programs).

dmd gives you COFF with -m64 or -m32mscoff (-m32 is the default is => OMF).

[...]
> Clearly, "main.d" needs to say "import lib_algo.utils". However, if I do
> this,
> I must add a module declaration in "lib_algo/utils.d", and I must change
> "lib_algo/test.d" so it says "import lib_algo.utils".

That's the way you're supposed to do it, yes. One source file <-> one 
module name.

> This is where it begins to feel clumsy. Why should lib_algo need to be
> modified in order to resolve an ambiguity happening in "myGame" ?

I don't know the exact reasons why the module system works like it does. 
Maybe you're on to something, maybe not. Anyway, here are some 
problems/surprises I see with your alternative idea (which basically 
means using relative file paths, if I get you right):

* You need to be aware of the directory structure when reading/writing 
code, as `import foo;` may mean different things depending on where you 
are. And you don't have a module declaration to tell you where you are.

* You're not able to copy imports from one file to another anymore.

* When moving a module, you have to update all its imports. You can 
introduce a subtle bug when you miss one, because the old import may 
still be valid but have a different meaning.

* The name of a module depends on the current working directory of the 
compiler run. You can't change directories between compiler calls and 
link the object files together.

* You can deliberately or accidentally import one source file under two 
different module names. Two modules from one source file is weird, 
especially when it happens accidentally.

* Can't just throw source files from different packages at the compiler 
anymore without thinking about their relative locations or the -I switch.

[...]
> Moreover, we saw earlier that this modification of the import done by
> "lib_algo/test.d" had consequences on the directory structure of lib_algo.
> In order to be able to build the test executable for lib_algo, I now
> need to
> have the following structure:
> $ find lib_algo
> lib_algo/lib_algo/options.d
> lib_algo/lib_algo/....
> lib_algo/lib_algo/array2d.d
> lib_algo/test.d
> (test.d can be put inside the inner "lib_algo")

Or, you know: `-I..` :P But changing the directory structure is probably 
nicer.

> Am I the only one to find this counterintuitive - and probably wrong?
> What am I missing there?

I don't think your alternative is obviously superior. The current way of 
having exactly one fixed name per module makes it easy to see what's 
going on at any point. You have to pay for that by typing a bit more, I 
guess.