On Wednesday, 5 June 2013 at 17:21:01 UTC, Jonathan M Davis wrote:
On Wednesday, June 05, 2013 14:02:37 Jakob Ovrum wrote:
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.
I honestly don't see how Phobos is in disagreement with the
module system. No,
it doesn't use hierarchy as much as it should, and there are a
few modules
that are overly large (like std.algorithm or std.datetime), but
for the most
part, I don't see any problem with its level of encapsulation.
It's mainly
just its organization which could have been better. My primary
objection here
is that it seems ridiculous to me create lots of tiny modules.
I hate how Java
does that sort of thing, but there you're _forced_ to in many
cases, whereas
we have the opportunity to actually group things together in a
single module
where appropriate. And having whole modules with only one or
two functions is
way too small IMHO, and that seems to be what we're proposing
here.
- Jonathan M Davis
I agree with one or two functions it's far too small, but I'm in
favour of having only one or two top-level classes/structs per
module (there will be exceptional cases but in general)
For examples:
std.regex - I think it would be better if each implementation had
its own module, plus a separate module for the parts common to
all of them. Importing std.regex would publicly import the lot
using the new package system.
std.range - module for tests, ie. isXXX and hasXXX, module for
algorithms ie. retro, take, etc., module for class wrappers
std.datetime - split each class/struct into own module, systime
alone is ~8000 lines
