On Sunday, 24 July 2016 at 15:33:04 UTC, Chris Wright wrote:
Look at std.algorithm. Tons of methods, and I imported it just
for `canFind` and `sort`.
Look at std.datetime. It imports eight or ten different
modules, and it needs every one of those for something or
other. Should we split it into a different module for each
type, one for formatting, one for parsing, one for fetching the
current time, etc? Because that's what we would have to do to
work around the problem in user code.
That would be terribly inconvenient and would just waste
everyone's time.
I agree with you, but I think you got me wrong.
Modules like std.algorithm (and nearly every other, in any
standard library) have very low cohesion. As you said, most of
the time, the whole module gets imported, although only 1% of it
is going to be used.
(selective imports such as "import std.algorithm : canFind;" help
you reduce namespace pollution, but not dependencies, because a
change in the imported module could, for example, change symbol
names.)
I guess low cohesion is OK for standard libraries, because
splitting this into lots of files would result in long import
lists on the user side, e.g:
import std.algorithm.canFind;
import std.algorithm.sort;
import std.algorithm.splitter;
(though, this seems a lot like most of us already do with
selective imports).
But my point wasn't about the extra compilation time resulting
from the unwanted import of 99% of std.algorithm.
My point is about the recompilation frequency of *your* modules,
due to changes in one module.
Although std.algorithm has low cohesion, it never changes
(upgrading one's compiler doesn't count, as everything needs to
be recompiled anyway).
However, if your project has a "utils.d" composed of mostly
unrelated functions, that is imported by almost every module in
your project, and that is frequently changed, then I believe you
have a design issue.
Any compiler is going to have a very hard time trying to avoid
recompiling modules which only imported something in the 99% of
utils.d which wasn't modified (and, by the way, it's not
compatible with the separate compilation model).
Do you think I'm missing something here?
