DIP16: Transparently substitute module with package

[Jonathan M Davis]

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

I only see the need to split of a module as the DIP suggests when it's too 
big, and if the documentation isn't large enough to be an issue, then I don't 
see how the module itself is going to be too large unless it has a ton of 
helper stuff, and that stuff can be seemlessy put in another, undocumented 
module without needing to create a package.

- Jonathan M Davis