[phobos] datetime review

[Denis]

On Sat, Oct 9, 2010 at 3:23 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>
> 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.
>

That's just a matter of preference, no one is pushing anyone to do so.
Everyone is free to choose the level of granularity that they want
when they import stuff.
Code separation isn't about that at all. After all from user's
perspective writing

import std.stdio : writeln;
import std.alorithm;

isn't any different from writing

import std.stdio.writeln;
import std.alorithm.all;

but there is quite a difference for code maintainer - in the latter
case all the related code is isolated, e.g. std.algorithm.sort only
contains stuff that it uses.

Imagine a D newcomer that is interested in the std.algorithm.sort
implementation. What we offer now is "dig into that mess the
std.algorithms is" (sorry, Andrei, std.algorithms is written well but
it is very similar to C++ <algorithm> header in terms of readability -
you need a *very* deep code knowledge to understand it).

On the other hand, "sort" (or any other class/method) only uses a
handful of other symbols (SwapStrategy, binaryFun, lessFun, sortImpl,
assumeSorted and a few others), but by and large it is very hard to
tell where this particular symbol comes from and it is quite hard to
jump back and forth between source files to find proper definition.
But it would be A TON easier if std.algorithm.sort was a (relatively)
small file with all the primitives used declared together, followed by
an implementation:

import std.functional.binaryFun;
import std.functional.lessFun;
import std.algorithm.isSorted;
...

/**
Sorts a random-access range according to predicate $(D less).
...
*/

SortedRange!(Range, less)
sort(alias less = "a < b", SwapStrategy ss = SwapStrategy.unstable,
Range)(Range r)
{
    ...
}

unittest
{
 ...
}

It's small, it's clean, it's easy to understand.

> 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.
>

I didn't tell you split datetime into a few modules, it's just there
is nothing wrong to do so, but current Phobos policy discourages (or
even prohibits) that.

> 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.

You certainly can do that, but you get little advantages and many
disadvantages for doing so.
Once again, it isn't any different from user point of view (same
namespace pollution, slightly increased compilation time in case of
import std.algorithm : sort; over std.algorith.sort), but it's very
different from code maintainer's point of view. It starts to matter *a
lot* when your source code grows large, and Phobos is already large.

> 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).

Not so obvious. Just compare tango.io.stream (has many submodules)
with std.stream (whole bunch of stuff merged):
http://dsource.org/projects/tango/docs/stable/
http://www.digitalmars.com/d/2.0/phobos/std_stream.html

> 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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>