module vs import

[Yigal Chripun]

Lars Ivar Igesund wrote:
> Tomasz Sowif1ski wrote:
> 
>> Robert Fraser Wrote:
>>
>>> The "module" keyword is used to assign a name to your module (which
>>> incidentally must coincide with its filename & folder structure) while
>>> "import" gives you access to the module with the given name.
>> By the way, why do you have to repeat the filename in the file itself? I'm
>> sure there must be some reason, but I can't see it now.
>>
>> Tomek
> 
> It is only really omittable if you have no hierarchy. The full module name
> is used in the symbol name mangling (for instance when compiling an object
> from a module using the -c switch). When you import the same module using
> the module name (say foo.bar.Util), your application will only link if the
> mangling (and module names match). The compiler can't guess the hierarchy
> specified by the importing code when that code isn't part of the compile.
> For all-at-once compiling, the compiler probably could get it right.
> 
> Lars Ivar Igesund
> blog at http://larsivi.net
> DSource, #d.tango & #D: larsivi
> Dancing the Tango

Personally I think that the current module/package model is broken. the
artificial distinction between modules and packages is wrong.
if I have a bunch of small classes, should I put them in one module/file
or have a different file for each class and group them together in a
package/folder? and more importantly, what if I choose to change between
having one huge file and having many small ones without changing the
logical hierarchy of my code?
it makes sense to put a big class in it's own file but then it's name
would be Name.Name (since the best name of the module is the same as the
contained class).
what if I want to separate the logical structure from the physical one
on disk (for a practical example - each sub project is handled by a
different team and has it's own sub-folder but this structure is
different from the structure of the API - Derelict's package structure
is a good example of such issues).
I usually do not like anything Microsoft does, but I have to admit that
their .net separation of physical assemblies on disk from logical
structure of the code in namespaces is genius. this is also tied with
the C++ model of compilation which D borrows. in C# there are no header
files at all, not even auto generated ones like D's .di files.

the latest DMD knows how to split obj files when creating a static lib.
thus the 1-1 relation between code units and the compiled binary units
is already broken. I think this should be taken to the next logical
level and the code organization should be separated from the
organization on disk. either the algorithm the compiler uses to find
symbols needs to change or  another flag can be added to the
makefile/dsss.conf that directs the compiler to the physical location of
symbols it needs (since we all use build tools anyway to compile code)
this is similar to a "project" file in a IDE.

regarding deployment:
Java jars contain a manifest file with metadata, so does .net
assemblies. that kind of file can and should be generated by the
compiler and it can contain the above mapping of logical modules to
physical locations inside the lib archive. this would be much better
than the traditional .a files and .so files.

--Yigal