[phobos] Split std.datetime in two?

[Steve Schveighoffer]

----- Original Message -----
> From:Andrei Alexandrescu <andrei at erdani.com>
> 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.

OK, source size.  But still, the "relevant" source size is small.  The unit test source size is large, but who's reading all the unit tests?  Won't people skip over those?

> 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 guess I just don't see it as a problem.  Source *size* doesn't concern me, quality does.

As for the amount of unittests, I feel like it's up to the developer to provide unit tests, and if he/she prefers to provide extra unit tests, that's fine.  I think the number of unit tests should be greater than 0, no upper limit.  And my unit tests are usually not looped because unit test failures usually give you a line that failed.  If you loop them, then you're not sure what loop iteration failed.

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

Sorry to also disagree :)  Veritcal space isn't code, documentation is not code, unit tests are code, but only relevant if you are reviewing unit tests.  LOC to me is the code that you have to read to understand how the library works.  unit tests don't qualify.  Most editors have folding ability or an ability to skip to the matching bracket.  This makes it irrelevant how many lines a unit tests occupies if you are skipping over it.

And if you aren't reviewing the library, you just want the API, you should be using the generated docs, which have nothing to do with LOC.

-Steve