On Thursday, 22 September 2016 at 14:29:20 UTC, Jonathan Marler
wrote:
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
I think that having package.d provides a better layout. Look at
the difference between this:
ls std/experimental
drw-rw-rw- allocator
drw-rw-rw- logger
drw-rw-rw- ndslice
-rw-rw-rw- typecons.d
and this:
ls std/experimental
drw-rw-rw- allocator
-rw-rw-rw- allocator.d
drw-rw-rw- logger
-rw-rw-rw- logger.d
drw-rw-rw- ndslice
-rw-rw-rw- ndslice.d
-rw-rw-rw- typecons.d
Having to put part of a package outside the package folder is
ugly to see and a bit more difficult to manage.
