DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, April 05, 2012 11:30:26 Steven Schveighoffer wrote:
>> A couple issues that still need consideration:
>>
>> 1. If std.algorithm the module becomes std.algorithm the package, what
>> happens with ddoc? We probably *do* need a compiler solution to this.
>
> That's assuming that you insist on keeping all of the documentation in  
> one
> file. That arguably defeats the purpose of splitting up the modules. If  
> there
> isn't enough in the module to split the documentation, then why do you  
> need to
> split the module?

I thought the whole point was code maintenance?  Not documentation  
splitting... I would have expected people to continue to treat  
std.algorithm like it was one module, even though it imports several  
sub-modules for its implementation.

>
> What _would_ be valuable and the package.d could provide is an overview  
> of the
> package. The ddoc comment for the package.d module can become the
> documentation for the package as a whole.
>
>> 2. deadalnix pointed out that if we come up with a scheme where the
>> package module and its submodules are in the same directory, the package
>> accessibility qualifier can be used (hey look, a use for the package
>> keyword!).
>
> Yes. std.datetime will need that once it's split. Without that, much of  
> it
> can't be split and/or code would have to be needlessly duplicated.

Hm.. I just thought of something, as long as the main "package" module  
imports everything from the same directory, and doesn't define anything,  
this isn't an issue.

-Steve