D modules/sourcecode organisation/filesystem mapping

[FunkyM]

Great post.

In article <e3vr42$1ths$1 at digitaldaemon.com>, Sean Kelly says...
>
>FunkyM wrote:
>> 
>> -> Imaging you have such a structure:
>> 
>> system.drawing.SomeEnum.TOP   -> /system/drawing.d
>> system.drawing.Bitmap         -> /system/drawing.d
>> system.drawing.Brush          -> /system/drawing.d
>> ..
>> 
>> -> At some point drawing.d becomes big/unmaintainable -> split sources
>> 
>> system.drawing.SomeEnum.TOP   -> CURRENTLY IMPOSSIBLE: packagename != modulename
>> system.drawing.bitmap.Bitmap  -> /system/drawing/bitmap.d with add. package lvl
>> system.drawing.brush.brush    -> /system/drawing/brush.d with add. package lvl
>
>Technically, I think this is untrue.  As the current module declaration 
>allows you to specify both the package and module name, you could 
>actually have multiple files with the same module declaration, compile 
>them separately, and provide a unified header (.di file) to clients with 
>all declarations in it.  In other words, the current scheme seems like 
>it could be made to work in a manner much like C/C++ include files with 
>a bit of effort.

VERY interesting idea. Now if this is working it would actually prove that the
idea of splitting sources is infact already supported (check last part, its
working). However, of course this approach uses the .di header files in a
different sense than they are supposed to be used (roughly, provide a way to not
supply the sources) and it introduces C/C++ like header usage requiring to
supply your element's definition.

>If the module scheme were to be modified, I think there are two options 
>that may be workable:
>
>1. Change 'module' to 'package' and infer the module name from the file 
>name since that's what is used for 'import' anyway.
>
>2. Have the header file generation option generate files based on the 
>module name, not the file name.  Thus this file:
>
>     // foo.d
>     module a.b.c;
>
>would create "a/b/c.di" in the target directory.  An extension of this 
>would be to offer some means of appending to the existing file if one 
>existed, so modules could theoretically be broken across multiple files. 
>  I'm not sure I entirely like this last idea as it breaks the idea of 
>one file per module, but as you say, it's possible that's actually 
>desirable in very large projects.

1. sounds what I actually had in mind with my proposal and it seems as a very
practical to me.

>> # Proposal "Solution A":
>> 
>> Introduce/change rules:
>> 
>> 1) Remove the limitation that a packagename can not be a modulename
>> 2) Change definition of "module" keyword to "defines the package of the current
>> module"
>> 3) The import statement qualified name maps to the filesystem
>> packages.modulename
>> (4) Optionally rename/change to a better keyword used in this context?)
>
>As above, I think the current method allows for this sort of thing if 
>you're willing to manually create your own header files.

I am not. ;)

> The purpose of the module declaration is to determine the mangled name
> of symbols in that file, and import necessarily refers to file names
> rather than module names.  So do something like this:
>
>     // src/a/b/foo.d
>     module a.b;
>
>     void doFoo() {}
>
>
>     // src/a/b/bar.d
>     module a.b;
>
>     void doBar() {}
>
>
>     // include/a/b.di
>     module a.b;
>
>     void doFoo();
>     void doBar();
>
>Note that I haven't tried this, but given my understanding of DMD I 
>think it would work.

I tried it and it works. It required me to compile all files individually but it
practically proved that the "merging package levels" is actually already
working/possible! (Also seems to be trivial)

However, the .di workaround, as you said, is similar to C/C++ include files
usage and one of the things D targets to get rid of. Therefore I see the
proposed solution ('module' to 'package') could really improve things.

The last issue to check if removing the packagename != modulename definition
does not create any problems in relation to this and the name mangling as noted
in another reply.

--- Martin Szulecki