DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 17:43:24 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
>> 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.
>
> I think we should be looking for a solution that not only allows  
> replacing module -> package transparently, but also allows people to  
> import the newly introduced fine-grained modules.

Of course you *can* do this.  I think you mean "and allows one to refer to  
the fine grained module as if it were imported from the top-level module".

I don't think that benefit is very great.  Why shouldn't we expect people  
to use the module name they actually imported to refer to a module?  If  
you want selective import, we have:

import std.algorithm : sort;

I think the real benefit to splitting up the module comes from being able  
to draw clear lines between which pieces of a large module are related.

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.*;

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.

-Steve