On Thu, 05 Apr 2012 17:02:13 -0400, Jonathan M Davis <[email protected]>
wrote:
On Thursday, April 05, 2012 15:26:14 Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 14:33:22 -0400, Jonathan M Davis
<[email protected]>
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
