D modules/sourcecode organisation/filesystem mapping

[Sean Kelly]

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.

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.

> # 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.  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.


Sean