www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: std.compress

On Wed, Jun 05, 2013 at 04:17:42PM +0200, David Nadlinger wrote:
 On Wednesday, 5 June 2013 at 11:30:10 UTC, John Colvin wrote:
Although I think you're right about having smaller modules, I
generally find it easier to browse through a larger file than many
smaller files.

On the contrary, I find extremely large files (like std.algorithm) very hard to navigate, because it's a hodgepodge of only loosely-related code, most of which is completely independent of the others. Which means there's no logical ordering to the code, they're just in arbitrary random order (and often not the same order they appear in the ddoc index). The only way to find stuff in code like this is to use the search function -- which is no different from looking up a different file in a well-organized module directory hierarchy.
Multiple files is ok if you know what you're looking for (grep) but
when you're just trying to scan across a system to get a feel for how
it's working, juggling many files is a real pita.

Try scanning through std.algorithm and tell me whether you "get a feel for how it's working". I tried doing that before, and got so lost 12% into the file that I've even less clue about how it all fits together than before I looked at the code. After the first 5 seconds or so, I'm just randomly paging up/down without any idea of where I am code-wise.
 Use an editor with a file tree sidebar? Quite on the contrary, I find
 many files to be much preferable, because you automatically have
 "bookmarks" in the source to come back to, and having the
 functionality already grouped in manageable logical units saves you
 from inferring that structure again, as it is the case when scrolling
 through a huge file.

 On a lighter note, if it's really a problem for you that module
 files are too small, what about just concatenating all the files in
 a given directory using a little shell magic? ;)

cat std/compress/*.d > /tmp/src.d; vim /tmp/src.d :) On Wed, Jun 05, 2013 at 04:20:49PM +0200, David Nadlinger wrote:
 On Wednesday, 5 June 2013 at 12:55:50 UTC, Andrei Alexandrescu
On 6/5/13 2:55 AM, 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):


I think that's nice.

+1. D has many powerful features for handling module namespacing (e.g. "import lzw = std.compress.lzw"), let's enable people to make use of them.

+1. Being D's standard library, Phobos really should be the standard example of how module namespacing should work. Right now it's just promulgating the bad practice of throwing a bunch of unrelated (or only loosely related) code in to giant monolithic files. C'mon, guys, this isn't 1975. We *have* tools for managing hierarchies of smallish files. There's no compelling reason why we have to stick to monolithic module design (or lack of design thereof) anymore. The biggest advantage of small modules is that code that doesn't depend on each other will not be lumped together in the same file. Why should they be? If you only use function X, why should the compiler do extra unnecessary work in parsing and compiling function Y, just because we arbitrarily lumped X and Y together for aesthetic (or whatever) reasons? Perhaps Phobos will be more palatable to the naysayers if using a single function doesn't, e.g., pull in a 5000-line std.algorithm. (Actually, std.algorithm currently sits at 11636 lines. I call BS on whoever claims to be able to "skim over" std.algorithm and "get a feel for how it works". Chances are your finger will get so tired of hitting PgDn about 2000 lines into the file that you won't even look at the rest. And most of the code is only superficially related to each other -- about 20 functions into the file you'd have lost track of all sense of how things fit together -- 'cos they *don't* really fit together! It's the epitome of why we *should* move to smaller modules, rather than the current giant monolithic ones.) T -- The right half of the brain controls the left half of the body. This means that only left-handed people are in their right mind. -- Manoj Srivastava
Jun 05 2013