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.