A suggestion for modules names / sharing code between projects

[Sebastien Alaiwan via Digitalmars-d]

Hi guys,

thanks a lot for your answers!

On Wednesday, 2 March 2016 at 22:42:18 UTC, ag0aep6g wrote:
> 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).
Thanks for the tip, I didn't know that.
I have actually deeper reasons for not using dmd (seemless 
cross-compilation, e.g "make CROSS_COMPILE=i686-w64-mingw32" or 
"make CROSS_COMPILE=arm-linux-gnueabi" without any special case 
in the Makefile ; and the way its unusual command line 
(-oftarget) conflicts with MSYS's path conversion, etc. ).

> 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):
Yes, I think we can say that.

I 100% agree with all the limitations you listed ; which makes a 
forced absolute-import system appear to be a lot more comfortable!

There's also one big limitation I see that you didn't list:
* If you're importing lib_a and lib_b both depending on lib_c, 
you need them to expect lib_c to be at the same path/namespace 
location. The current module system guarantees this, because all 
package names are global.

(And linking with precompiled binaries might become a nightmare)

However, using global package names means you're relying on the 
library providers to avoid conflicts, in their package names, 
although they might not even know each other. Which basically 
implies to always put your name / company name in your package 
name, like "import alaiwan.lib_algo.array2d;", or "import 
apple.lib_algo.array2d".
Or rename my "lib_algo" to something meaningless / less common, 
like "import diamond.array2d" (e.g Derelict, Pegged, imaged, 
etc.).

If, unfortunately, I happen to run into a conflict, i.e my 
project uses two unrelated libraries sharing a name for their 
top-level namespace, there's no way out for me, right?
(Except relying on shared objects to isolate symbols)

> I don't think your alternative is obviously superior.
Me neither :-) I'm just sharing my doubts about the current 
system!

> 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.
Yes, I guess you're right.

I'm going to follow your advice and Mike's for my projects, this 
will allow me to see things more clearly. Anyway, thanks again to 
all of you for your answers!