[phobos] datetime review

[Jonathan M Davis]

On Saturday 09 October 2010 03:46:42 Denis wrote:
> This is an interesting discussion that I personally find very important.
> 
> One of the most annoying things in Phobos is that modules are too
> large and by too large I mean they contain lots and lots of stuff that
> are loosely related to each other.
> 
> I'm strongly against design like that. As a programmer I've been grown
> with idea of module separation in mind. At work, we are spending tens
> of hours discussing the same problem: code dependency reduction. In
> Phobos, it's just a disaster - every module is a monster that heavily
> depends or other monsters alike.
> 
> I've heard an opinion that it's hard for people to remember too many
> modules names. However, they know that you need to import std.array to
> use Appender, or std.algorithm to use sort etc. As such, it shouldn't
> be any harder for them to import std.algorithm.sort; or import
> std.array.appender; Alternatively, they may import std.algorithm.all
> and have the whole bulk of features at their disposal, but from my
> experience, that's not what is needed anyway. Here is a random import
> snippet from my code:
> 
> import core.memory : GC;
> import core.atomic : cas;
> import core.stdc.string : memcpy;
> import core.sync.semaphore : Semaphore;
> 
> In ddmd, I have
> 
> module dmd.expression.Add;
> module dmd.expression.And;
> module dmd.expression.ArrayLength;
> etc
> 
> each declaring just *one* method and only imports stuff that that
> particular module needs. It helps reducing module dependencies *a
> lot*.

I, on the other hand, think that it's horrible to be importing functions or 
types individually. I'd sooner want to import the entirety of Phobos than import 
an individual function.

Now, you don't want modules to get too large to be sure, but I'm not aware of a 
single module at this point that I'd consider too large. std.container may get 
that way once it has a full complement of containers, but none are currently 
what I'd consider too big. My datetime code is pushing it as a single module, 
but I don't think that it's really a problem that way except that the file itself 
gets quite large.

Certainly, it's far easier to know that an algorithm is likely to be in 
std.algorithm than to have a host of different modules with different types of 
algorithms in them and have to figure out what is where. Obviously some stuff 
splits out fairly nicely (like string and range being their own modules), but 
taking something like the Java approach and essentially having a class per 
module would create _way_ too many modules. I think that, for the most part, the 
current module scheme in Phobos is pretty good. I expect that we'll have to 
breakdown at some point and introduce a multi-level hierarchy for at least some 
modules rather than have the module hierarchy be entirely flat, but for the most 
part, what we have is good. What we lack is functionality, not good module 
layout.

And really, if for some reason which I can't comprehend, you actually _want_ to 
import functions individually (like you and various other folks out there seem 
to like to), you can still do that. And as soon as you're importing them 
individually, they could each be in their own module for all it matters with 
regards to importing (though obviously that would be bad for the documentation). 
So, I'd say that it's generally better to have modules that are on the large 
side rather than on the small side.

- Jonathan M Davis