Module Clarification
Jonathan Marler via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu Sep 22 07:29:20 PDT 2016
On Thursday, 22 September 2016 at 11:40:17 UTC, Steven
Schveighoffer wrote:
> This should be fine. x/package.d is equivalent to module x.
Ok, it looks like no-one thought what I was doing was off-base. I
guess this brings up another question. Why doesn't the compiler
support modules in a hierarchy?
foo.d
foo/bar.d
The only reason I can see is that you would have to setup some
rules on how to handle it when you have both a module file, and a
package.d file in a directory with the same name:
foo.d
foo/package.d // huh? error?
Actually, the more I think about it, I'm not sure there's a good
reason for the "package.d" semantics to exist. I guess it
establishes a pattern when people would like to combine smaller
modules into one public module, but it doesn't have to be used
that way. The opposite is true that you could use a normal
module (not a package.d module) to publicly import smaller
modules:
Instead of:
foo/package.d // publically imports fooPart1 and fooPart2
foo/fooPart1.d
foo/fooPart2.d
What was wrong with:
foo.d // still publically imports fooPart1 and fooPart2
foo/fooPart1.d
foo/fooPart2.d
If the package.d file didn't exist, then I don't think there
would be any problem with hierarchical modules. Is this the
right conclusion? Was package.d a mistake? Maybe the reasoning
is that D doesn't really like hierarchical modules, so creating
them should look a bit odd?
foo/package.d
foo/bar/package.d
foo/bar/baz/package.d
More information about the Digitalmars-d-learn
mailing list