On 9/21/16 10:17 AM, 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 is not a requirement for the package.d usage. You can do anything you want in package.d

For example, in std/experimental/allocator/package.d, sub modules are not imported unless you do it yourself.

 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?

This should be fine. x/package.d is equivalent to module x.


Reply via email to