std.compress

[Walter Bright]

On 6/5/2013 12:29 AM, Jonathan M Davis wrote:
> On Wednesday, June 05, 2013 00:14:59 Walter Bright wrote:
>> When two modules have nothing to do with each other, they should be in
>> separate modules.
>
> Except that they're all compression algorithms, so they _are_ related.

No, they are not related. They don't share code, and it is unlikely more than 
one would be called in any particular use case.

Remember, module contents have private access to other parts of the module. This 
violates encapsulation when the parts are unrelated.

> Having
> modules that are only a few hundred lines long is very counterproductive IMHO.

Why?

On the other hand, when you are trying to understand a module, having thousands 
of lines of things that have no connection to each other makes it difficult. It 
also makes debugging them harder than necessary.

> It's highly annoying how Java insists on splitting everything up into different
> files. You end up with a lot of small files to wade through.

Wade through for what? If you're having a problem with the lzw compressor, why 
would you find it more productive to wade through the huffman compressor to get 
to it?

> Fortunately, D
> doesn't force that, and I don't think that we should go that route by choice.
> There's no more reason to split all of these up then there is to put each
> algorithm in std.algorithm in its own module. And yes, I know that you like
> that idea, but it seems ridiculous to me to try and have only one or two
> functions per module. We don't want them to be huge, but having them be very
> small is just as harmful IMHO.

You need a better case as to why it is harmful.

I've spent many miserable hours trying to find a bug in a phobos module that is 
a zillion lines of code, trying to strip out what is not necessary to repro the 
problem.

I don't see what problem kitchen sink modules solve - my experience is that 
smaller, better contained abstractions are more productive than kitchen sinks.