DIP16: Transparently substitute module with package

[Jonathan M Davis]

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