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.
