[phobos] Split std.datetime in two?

[Jonathan M Davis]

On Thursday, February 10, 2011 07:15:44 Andrei Alexandrescu wrote:
> On 2/10/11 7:59 AM, Steve Schveighoffer wrote:
> > Agree 100%. Leave the module as-is and let's improve the doc generator.
> > I don't think we should design the functionality of code around
> > documentation issues.
> 
> Same here. There are two additional options we have:
> 
> - Reduce the size of the documentation. Jonathan is not the tersest guy
> I know, and there is a fair amount of repetitiveness in the
> documentation. For example DateTime opBinary comes with a full table
> with four rows and five columns that conveys the simple fact that adding
> or subtracting a duration to a DateTime yields a DateTime. That and many
> other tables have identical rows (I think it's a cut and paste error;
> the idea might have been to swap the order of arguments, yet _still_ a
> table is not justified there).
> 
> - Write a separate document about dates and times in the form of a
> manual, and reduce the size of the documentation proper. Insert
> references to the manual.
> 
> Now that the topic came about I have serious concerns about code and
> functionality density of Phobos going forward, and that I promised
> myself to be extra hawkish about it.
> 
> std.datetime has 34219 lines, which accounts for over 26% of the entire
> Phobos size. If Jonathan will (as he promised, I didn't forget :o)) fix
> line sizes to conform to 80 columns, then std.datetime will become 40961
> lines, or straight 30% of Phobos.
> 
> (This might have to do with the increase of "hello, world" that was
> noted by some people on the compiler list.)
> 
> I understand there are factors that contribute to that: date and time
> manipulation is a bulky endeavor, there's a ton of unittests, and
> there's a lot of documentation. But at a level I find it difficult to
> digest the fact that in sheer numbers date and time manipulation
> accounts for 30% of Phobos. As a comparison point, std.algorithm does
> arguably a lot of work, has adequate documentation, and has unittest
> coverage at 95%, yet does all that in a "measly" 8027 lines.
> 
> Now say we added std.unittests exactly as proposed. It has 2247 lines,
> which puts it at 73 percentile in terms of LOC in Phobos - just below
> std.stdio and above workhorses such as std.random, std.variant, and
> std.concurrency itself. Again, I find it difficult to convince myself
> that a few unittest support functions and their paraphernalia need that
> much real estate.

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

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.

If we really want to know why hello world is so large, I think that we need to 
do as Walter suggests and actually investiage that with -map. std.datetime 
almost certainly does contribute to that, but so much of it is unit tests that I 
have a hard time believing that it did all that much to increase the size of the 
binary. And the reality of the matter is that as the functionality of Phobos 
increases, the amount of code that it has will increase. And as long as all D 
binaries are statically linked, that means that the size of the binary is going 
to increase. That's just a fact of life. And if the standard libraries of Java 
and C# are any indication of the typical size of a standard library, then Phobos 
could get quite large eventually. Obviously, that takes time and effort, so 
Phobos is not going to be enormous like that any time soon, but it's size _is_ 
going to continue to increase if we want a full-featured standard library.

- Jonathna M Davis


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