DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:

>> I don't see how. Just move the code into another module and publicly
>> import that module from std/algorithm.d. Problem pretty much solved.
>
> The issue is code organization. If you want to split up std.algorithm (or
> std.datetime or whatever) into multiple modules, you have to create a new
> package with a completely different name with no connection to the  
> original
> save for the fact that the original publicly imports it.

My view is that people will not import the smaller modules, they will only  
ever import std.algorithm.

Look at std.bigint, which imports modules from std.internal.math.  Nobody  
ever imports std.internal.math.??? because they just import std.bigint.

>> BTW, importing a directory was already proposed in DIP15.
>> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP15
>
> Yes, but having a package.d with the public imports gives you much finer-
> grained control over what gets imported, and DIP15 doesn't solve the  
> problem
> of fully qualified uses of std.alorgithm.sort not breaking when
> std.algorithm.sort gets moved to something like std.algorithm.sorting.d.

I think you are forgetting that all current code imports std.algorithm,  
which will register the symbol std.algorithm.sort via public import.  No  
code will break, even if it uses FQN.

The only way to "break" code is to write new import statements.  I don't  
think anyone will do that unknowingly.

-Steve