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