std.compress

[Diggory]

On Wednesday, 5 June 2013 at 17:21:01 UTC, Jonathan M Davis wrote:
> On Wednesday, June 05, 2013 14:02:37 Jakob Ovrum wrote:
>> We have a standard library in disagreement with the language's
>> encapsulation mechanics. The module/package system in D is 
>> almost
>> ignored in Phobos (and that's probably why the package system
>> still has all these little things needing ironing out). It 
>> seems
>> to owe influence to typical C and C++ library structure, which 
>> is
>> simply suboptimal in D's module system.
>
> I honestly don't see how Phobos is in disagreement with the 
> module system. No,
> it doesn't use hierarchy as much as it should, and there are a 
> few modules
> that are overly large (like std.algorithm or std.datetime), but 
> for the most
> part, I don't see any problem with its level of encapsulation. 
> It's mainly
> just its organization which could have been better. My primary 
> objection here
> is that it seems ridiculous to me create lots of tiny modules. 
> I hate how Java
> does that sort of thing, but there you're _forced_ to in many 
> cases, whereas
> we have the opportunity to actually group things together in a 
> single module
> where appropriate. And having whole modules with only one or 
> two functions is
> way too small IMHO, and that seems to be what we're proposing 
> here.
>
> - Jonathan M Davis

I agree with one or two functions it's far too small, but I'm in 
favour of having only one or two top-level classes/structs per 
module (there will be exceptional cases but in general)

For examples:
std.regex - I think it would be better if each implementation had 
its own module, plus a separate module for the parts common to 
all of them. Importing std.regex would publicly import the lot 
using the new package system.

std.range - module for tests, ie. isXXX and hasXXX, module for 
algorithms ie. retro, take, etc., module for class wrappers

std.datetime - split each class/struct into own module, systime 
alone is ~8000 lines