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

Reply via email to