On Tuesday, June 04, 2013 23:55:05 Timothee Cour wrote:
> What I suggested in my original post didn't involve any indirection/abstraction; simply a renaming to be consistent with existing zlib (see my points A+B in my 1st post on this thread):
> 
> std.compress.zlib.compress
> std.compress.zlib.uncompress
> std.compress.lzw.compress
> std.compress.lzw.uncompress
> 
> same reason we have: std.file.write, std.stdio.write, etc, and not std.fileWrite, std.stdioWrite.

So, you want to create whole modules for each compression algorithm? That seems like overkill to me. What Walter currently has isn't even 1000 lines long (and that's including the CircularBuffer helper struct). Splitting it up like that seems like over-modularation to me.

- Jonathan M Daivs

On 6/4/2013 11:59 PM, Jonathan M Davis wrote:
> So, you want to create whole modules for each compression algorithm?

Yes.

> That seems like overkill to me. What Walter currently has isn't even 1000 lines
> long (and that's including the CircularBuffer helper struct). Splitting it up
> like that seems like over-modularation to me.

When two modules have nothing to do with each other, they should be in separate modules.

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. Having modules that are only a few hundred lines long is very counterproductive IMHO. 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. 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.

- Jonathan M Davis

On 2013-06-05 08:59, Jonathan M Davis wrote:

> So, you want to create whole modules for each compression algorithm? That
> seems like overkill to me. What Walter currently has isn't even 1000 lines
> long (and that's including the CircularBuffer helper struct). Splitting it up
> like that seems like over-modularation to me.

The current modules in Phobos already contains too much. We shouldn't make the same mistake again.

-- 
/Jacob Carlborg

On Wednesday, June 05, 2013 09:31:01 Jacob Carlborg wrote:
> On 2013-06-05 08:59, Jonathan M Davis wrote:
> > So, you want to create whole modules for each compression algorithm? That seems like overkill to me. What Walter currently has isn't even 1000 lines long (and that's including the CircularBuffer helper struct). Splitting it up like that seems like over-modularation to me.
> 
> The current modules in Phobos already contains too much. We shouldn't make the same mistake again.

Maybe some do, but many don't, and 1000 lines is _far_ from too much. If we start making modules that small, we're going to end up with tons of them to wade through to find anything.

- Jonathan M Davis

On Wednesday, 5 June 2013 at 00:58:02 UTC, Walter Bright wrote:
> On 6/4/2013 5:13 PM, Marco Leise wrote:
> Actually, I've often thought of making dmd able to read everything it needs out of a zip file.

I support that. It would make distributing source code cleaner. Most of the time you don't need to look at the code, just compile it, while still knowing that you have it available in an archive if you need it.

Maybe that kind of support could improve the distribution of closed-source libraries, too: the generated .di files and the binaries could be packaged together in a zip file.

More, the zip file could be really easy tested for self-containment. It happens sometime that a folder of code compiles, then when you package the whole thing and ship it, you discover that you forget to package inside some kind of file/dependency, and the customers are complaining about it.

With a zip file, you just do a compile-check on the final package and, if ok, then it is ready for shipment.

Btw, I cannot not resist, just adding here my favorite quote in software development:

"It compiles. Let's ship it!" :)

On Wednesday, 5 June 2013 at 02:23:54 UTC, Marco Leise wrote:
> Am Tue, 04 Jun 2013 17:58:01 -0700
> schrieb Walter Bright <newshound2@digitalmars.com>:
> That would have been difficult for editors and IDEs that can
> look up file names from include paths only when they are not
> zipped up. It is good the way it is.

True, but Java also had the same issue with its .jar files and the editors adapted.

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.

On 6/5/2013 12:38 AM, Jonathan M Davis wrote:
> Maybe some do, but many don't, and 1000 lines is _far_ from too much. If we
> start making modules that small, we're going to end up with tons of them to
> wade through to find anything.

1. It isn't any harder to find things in multiple files than in one file.

2. If there's a ton in one file, you have to wade through the ton to find what you're looking for.


Your argument has merit if you are using a floppy disk drive for storage, as floppies are agonizingly slow to read files off of. But that problem disappeared 30 years ago.

(At an SD conference back in the 80's, I was on a compiler panel with the compiler guys from Microsoft, Borland, etc. We were each asked how our respective compilers worked on floppy systems. The guys would say "well, you set it up this way, configure it that way, juggle what goes on which floppy, and you can do it!" I was the third of five guys, and my response was:

"We charge $200 extra for the floppy disk development system, and ship you a hard disk with it."

That was the end of that discussion, and I never heard that question again.

On 2013-06-05 02:58, Walter Bright wrote:

> Actually, I've often thought of making dmd able to read everything it
> needs out of a zip file.

I think it's better to have a proper package manager.

-- 
/Jacob Carlborg