On Wednesday, 5 June 2013 at 07:39:12 UTC, 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.
- Jonathan M Davis
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.
Third-party libraries tend to do a much better job at this. For
example, Tango goes all out and embraces the package and module
system, and the result is an extremely organized tree of modules
with appropriate granularity. Code isn't hard to find because
everything isn't just dumped into (bloated) blobs in a flat
structure like in Phobos; it's organized into a tree. It seems
like a no-brainer with the D language, and Phobos is the only D
library I know that doesn't embrace this style of organization.
The result is awful coupling throughout; with Phobos, we can't
even write Hello World without pulling in half of the standard
library.
It's not just about the actual dependencies a module has, but the
perceived dependencies; important from a readability perspective.
I know a lot of D programmers embrace selective imports when
working with Phobos, because just seeing a plain import statement
such as "import std.datetime;" tells you very little about what
the importing module actually does, and it's harder to figure out
exactly where unqualified symbols come from when reading the
module's code.
I think the programmer should have a choice of convenience versus
readability/fine dependency management when importing. The
current module system does a decent job at enabling this already,
and it's bound to get better with improvements like DIP37.
Scripts and certain application code may want to prioritize
productivity over finely managed dependencies, while library code
- especially the *standard* library! - should definitely aim for
lean coupling that makes sense.
To that end, I think a lot of improvements can be made without
breaking user code, but I'd be very much willing to see all kinds
of breakage if it means we can get rid of the present standard
library of substandard quality. The language may have been
declared stable, but Phobos is in no laudable state.
