A suggestion for modules names / sharing code between projects

[Laeeth Isharc via Digitalmars-d]

On Thursday, 3 March 2016 at 06:53:33 UTC, Sebastien Alaiwan 
wrote:
> 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)

See modules doc page off dlang.org.
import io = std.stdio;
void main()
{ io.writeln("hello!"); // ok, calls std.stdio.writeln
std.stdio.writeln("hello!"); // error, std is undefined
writeln("hello!"); // error, writeln is undefined
}

Also static import and scoped imports.