Module Clarification

tcak via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Sep 21 19:17:06 PDT 2016


On Wednesday, 21 September 2016 at 14:17:56 UTC, Jonathan Marler 
wrote:
> 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?

I can be wrong, but if I remember correctly, when I used 
package.d as you do a while ago (~1.5 years ago), it was acting a 
little different compared to a normal module file. Some 
declarations were not working as in a normal module. It could be 
my bad observation as well. I hope it works for you, but your 
design might break at some point.


More information about the Digitalmars-d-learn mailing list