[phobos] Split std.datetime in two?

[Andrei Alexandrescu]

On 2/10/11 11:33 AM, Jonathan M Davis wrote:
> Well, as Steven says, most of std.datetime is unit tests. And probably over half
> of the rest is documentation, since most of the functions themselves are
> relatively short and simple.

That means there are too many unit tests. There is such a thing as too 
much of a good thing.

> Add to that that I tend to like a fair bit of
> vertical space in my  code (e.g. return statements pretty much always have a
> blank line above them), and how I code tends to take up a fair bit more LOC than
> you would without actually being more code.

As I mentioned, it would be courteous to your other colleagues if you 
were more economical with vertical space. Many people (and most of 
Phobos devs) consider vertical space a rare commodity.

> It wouldn't surprise me that if I
> were to format std.algorithm in a manner that I'd typicall write it, it would at
> least double in line count simply due to additional blank lines that I'd
> introduce for code legibility.

I consider legible code compact code that I can keep on one screen and 
understand what it does.

> And, of course, if I'd written std.algorithm, it
> would almost certainly have had quite a few more unit tests. None of that
> increases the size of the actual binary.

It's not the size of the binary I'm worried about.

> I don't think that std.datetime is the
> largest module in Phobos, but I do think that comparing its line count to
> something like std.algorithm really tells you how much of a difference it makes
> in the size of the binary - especially when so much of it is unit tests which
> wouldn't end up in a binary.

One thing is certain: someone who wants to take a look at std.datetime 
has the prospect of navigating 34KLOC.

> The unit testing functions I wrote are pretty much in the same boat. They had
> thorough unit tests - testing not only all of its code paths (which is what the
> % code coverage gives you) but an appropriate range of values. The functions
> themselves weren't all that long.

They are unrolled loops that should be rolled. Most likely they test the 
same thing several times.

> P.S. Weren't you considering increasing the character limit beyond 80? I'm not
> about to go and edit std.datetime for line width until that's definitely decided.
> At the moment, I'm working on improving the documentation (mostly for
> consistency rather than length, though its length should be somewhat reduced
> when I'm done) and that will make the documentation and examples at most 80
> characters wide, but I haven't started in on the rest of it yet. Most of the
> long lines are unit tests though, I believe (some of which are ludicrously long
> simply because it's easier to read an assertion on a single line).

Generally I don't want to impose something as much as us all reaching a 
consensus about it. Some of Phobos people (I recall you and Don) prefer 
larger limits. On the other hand, there _are_ some things that will 
never reach an agreement so someone needs to just set some limits.


Andrei