On Friday, November 03, 2017 16:32:52 H. S. Teoh via Digitalmars-d-learn
wrote:
> <half-serious> Perhaps the solution is to go the
> one-overload-set-per-file route, with std/algorithm/package.d basically
> importing everything underneath. :-P </half-serious>
>
> (Shhh, don't tell Andrei, or we'll get another lecture about wasting
> time on worthless things while more important things are left to do.)
Actually, when Daniel and I were trying to talk Walter into adding the
package.d feature so that std.datetime could be split up without breaking
code, Walter made a comment about how he didn't see any problem with there
being a function per module. So, he might be on board with code arrangements
along those lines, but I have no idea about Andrei.
Personally, I think that splitting stuff up that far makes it a pain to deal
with, even if it might help the implementation sometimes. It's already
really annoying that I have to figure out which module something in
std.algorithm is in now, because the style check junk that has been added to
Phobos requires that you not only use selective imports but that you use the
module that it's directly in, so you can't do something like
import std.algorithm : map;
but instead have to go figure out which module it's currently living in and
add that after std.algorithm.
Of course, I also don't generally have a problem with large modules. They
_can_ become large enough to become a problem, but I've found that I have a
much higher tolerance for how much goes in a single file than many of the D
devs seem to have. IMHO, the main thing that starts causing problems with
large modules is when you start doing stuff like using attribute labels like
@safe:
or attribute blocks like
@safe
{
}
because then it becomes difficult to know which attributes actually apply to
a piece of code.
Most stuff is self-contained enough that having a bunch of stuff in a single
module frequently isn't a real problem. So, if they're related enough, I
have no problem with it. But good organization is arguably difficult to get
right and highly subjective - just like naming stuff is.
Where you risk running into serious problems is where you have a large
module full of interdependent stuff, because then it's all highly coupled
and hard to keep track of, so it becomes hard to understand and maintain.
You can have the same problems across modules, but when you split stuff up
across modules, it tends to force you to think about things differently so
that you don't make everything so highly coupled - though a bad programmer
(or a good programmer having a bad day) can make any code a mess.
- Jonathan M Davis
