• "H. S. Teoh" <hsteoh quickfur.ath.cx> Jun 05 2013

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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.


+1.


 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
 wrote:
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):

std.compress.zlib.compress
std.compress.zlib.uncompress
std.compress.lzw.compress
std.compress.lzw.uncompress


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