module vs import

[Yigal Chripun]

Lars Ivar Igesund wrote:
> Yigal Chripun wrote:
> 
>> 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.
> 
> This has been discussed before, and I agree that the current situation isn't
> ideal for refactoring the codebase, and there is also the estetic issue you
> mention (Name.Name). Dropping the current restrictions would incur more
> prolems with ambigiuty when resolving the hierarchy. And note that your
> example about the new DMD feature regarding object files really doesn't
> compare - they're more akin to split the source for a modules interface
> into several implementation files, and thus not in conflict with the
> current module naming scheme.
> 
> Oh, and there is a difference between "broken" and "not perfect". The
> current scheme does work, so it can hardly be considered broken.
> 
> Lars Ivar Igesund
> blog at http://larsivi.net
> DSource, #d.tango & #D: larsivi
> Dancing the Tango

I don't see any /new/ problems of ambiguity with such a scheme. The
compiler will just use two completely separate mechanisms - one for
resolving physical locations (i.e. files/directories) and another for
resolving the logical hierarchy of symbols.

maybe my saying that the current system is broken was too strong, but it
definitely is not perfect and has issues. as the saying goes:
"good enough is the enemy of perfect"
I prefer to side with perfect while others may choose otherwise. I
wonder what is Walter's position in this regard.

--Yigal