DIP16: Transparently substitute module with package

[Steven Schveighoffer]

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

> On Thursday, April 05, 2012 15:26:14 Steven Schveighoffer wrote:
>> 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.
>
> If the module isn't large enough to be split for documentation, I find  
> it hard
> to believe that it needs to be split for maintenance.

Why do we ever need to split modules for documentation?  Just fix the doc  
generator so it's not as monolithic.  For instance, have one page per  
class or struct.

> And if all you care
> about is sub-modules for implementation and want all of the functions in  
> the
> same module still, then this DIP is pointless. All you have to do is  
> declare
> undocumented sub-modules which hold the various implementations and have  
> the
> actual module call them. We already do this sort of thing in Phobos to  
> get
> around static destructors screaming about circular dependencies.

You are starting to see my point :)  But I think the issue is not so much  
that you are splitting the implementation, but splitting up the API into  
related modules.

For example, std.container.  Imagine we have a robust set of 15  
containers.  Why should those all be in one file?  They have nothing to do  
with eachother except they are in the same namespace.  Why does  
RedBlackTree need to be able to access the internals of Array?

As the writer of RedBlackTree, I want to be able to test and develop my  
container without having to worry about the rest of std.container.  But I  
also would like to have the FQN of it to be std.container.RedBlackTree.   
Public imports allow this *today* without any changes.

Note that size isn't so much an issue for me as being able to  
compartmentalize and develop individual pieces of a module.

-Steve