On Friday, April 06, 2012 08:09:28 Steven Schveighoffer wrote: > I feel like most people will still import the main package module, and not > the submodules. I don't think I ever wrote a piece of java code that > didn't have: > > import java.io.*;
Which is actually considered bad practice in Java, though a lot of people do like to do it. What's generally considered good practice is to explicitly import every module/class, and Eclipse likes to underline imports in red if you don't. > I keep coming back to std.container. Already it's large, and full of > unrelated types. It's only going to get worse. > > Now, I fully agree that having some way to import a package by itself > without having to import all its modules would be ideal (as well as > splitting a large module into submodules that live in the same > namespace). I think DIP15 has that covered. DIP15 doesn't fix the explicit path problem though. You can't change std/algorithm.d into std/algorithm/ (with sorting.d, search.d, etc.) without breaking code. You could make std/algorithm.d publicly import std/alg/* and then DIP15 would allow you to import std.alg to get all of its sub-modules, but you're still forced to use a module to publicly import symbols as part of a migration path, and you can't split a module in place. DIP15 also less powerful than having a package.d, since it'll automatically import ever public symbol when it may be desirable to have it only import a subset of them or to publicly import something from another module (e.g. as part of a migration path - like moving the benchmarking code in std.datetime to std.benchmark rather than lumping it with the std.datetime stuff when it's split into separate modules). That may or may not be a big deal, but it does mean that DIP15 isn't as powerful as DIP16's package.d solution in that regard. DIP15 also doesn't give a means of documentating a package. By having a package.d file, we have a really good place to provide an overarching description for the package in ddoc. So, while I don't like the second part of DIP16 at all (i.e. the std.sort stuff), I think that the package.d part is a much better way to go. - Jonathan M Davis