Module Clarification

Jonathan Marler via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Sep 21 07:17:56 PDT 2016


I'm working on a code generation tool and wanted to make sure my 
module approach was correct.  The generated code has a module 
hierarchy, where modules can appear at any level of the hierarchy.

module foo;
module foo.bar;

In this case, module foo and foo.bar are independent modules.  
The foo module does not publicly import foo.bar, like a typical 
package.d module would do. At first I organized the modules like 
this:

foo.d     (module foo)
foo/bar.d (module foo.bar)

But this doesn't work because the module file foo.d, cannot have 
the same name as a the directory foo.  So now I organize it like 
this:

foo/package.d (module foo)
foo/bar.d     (module foo.bar)

This is not the typical usage for the "package.d" file.  
Normally, package.d would publicly import other modules, however, 
in this case, package.d is an independent module.  This also 
means that if another module was added, say foo.bar.baz, the new 
file system would have to look like this:

foo/package.d     (module foo)
foo/bar/package.d (module foo.bar)
foo/bar/baz.d     (module foo.bar.baz)

This technique seems a bit odd, but it works.  I'm just wondering 
if there's a better way to achieve these semantics, or if this is 
the appropriate solution?


More information about the Digitalmars-d-learn mailing list