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.
