[phobos] Split std.datetime in two?

[Andrei Alexandrescu]

On 2/10/11 9:50 AM, Steve Schveighoffer wrote:
> ----- Original Message -----
>> From:Andrei Alexandrescu<andrei at erdani.com>
>> 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 don't think so, but I cannot be sure. I'd say a full 75-90% of
> std.datetime is unit tests or documentation.  That shouldn't increase
> the size of the lib, and certainly not by as much as it does.

It increases the size of the source that someone looking at the library 
must navigate and absorb.

In case I wasn't clear: my concern is source size. I am now sorry I 
mentioned library size, and twice so because I didn't verify the hypothesis.

It is difficult to believe that a library needs that much unittests in 
terms of sheer size. The more I browse through std.datetime, the more 
firmly my hair is standing up on my head. It's most all large 
hand-unrolled loops. I am now sorry I voted for the library without 
having raised a flag at this very serious problem. I didn't realize its 
size back then.

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

> Lines of file does not mean % of a library, especially when a large
> portion of it is not compiled.  I think we need to stop this
> prejudice against uncompiled LOC.  I fully support having unit tests
> next to the code being tested, it's the whole point of the builtin
> unit test system in D.

I am sorry, I disagree with discounting LOC. LOC is LOC. Compiled or 
uncompiled it is intellectual overhead. We need to write good code, code 
that we provide as living examples on how to write quality programs. 
Good code is not unrolled loops. Well, except sometimes :o).

> Bottom line, the doc generator should do a better job of generating
> documentation, so we don't *have* to open the file, and if
> std.datetime is adding too much binary to the exe, we should fix
> whatever problems dmd is likely having there.

I agree.


Andrei