On Thursday, April 05, 2012 15:26:14 Steven Schveighoffer wrote: > On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis <jmdavisp...@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