On Thursday, 22 September 2016 at 15:02:01 UTC, Lodovico Giaretta
wrote:
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.
Yes that does seem like a nice benefit. What do you think about
hierarchical modules? Do you think we should have supported
modules that also have modules underneath them? i.e.
foo.d
foo/bar.d
foo/bar/baz.d
Or do you think it's fine to require the higher level modules to
exist in package.d files?
foo/package.d
foo/bar/package.d
foo/bar/baz.d
It just seems odd because the modules aren't packages. I suppose
I would understand if hierarchical modules are discouraged, is
that the case? I ran into this problem because I'm working on a
.NET to D transpiler, and put all the symbols in a .NET namespace
into the same D module. So currently I have to do this:
System/package.d
System/Net/package.d
System/Net/Sockets.d
but I think it would make more sense to have this:
System.d
System/Net.d
System/Net/Sockets.d
