[phobos] Split std.datetime in two?

[Andrei Alexandrescu]

On Feb 11, 2011, at 12:00 AM, Steve Schveighoffer  
<schveiguy at yahoo.com> wrote:

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

All code is relevant.

> The unit test source size is large, but who's reading all the unit  
> tests?

People who look at the file.

> Won't people skip over those?

Skipping is overhead, particularly when relevant content is drowned in  
a sea of chaff.


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

This goes without saying.

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

Honest, I felt the same but datetime proved me exaggeration is harmful.

> I think the number of unit tests should be greater than 0, no upper  
> limit.

Again I used to think the same. I've since recanted.

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

Vertical space is informational real estate.

> LOC to me is the code that you have to read to understand how the  
> library works.

LOC is loc, period.

> unit tests don't qualify.
> Most editors have folding ability or an ability to skip to the  
> matching bracket.

Structured editors are definitely helpful. I don't want to /require/  
one for viewing phobos.

>  This makes it irrelevant how many lines a unit tests occupies if  
> you are skipping over it.

It is relevant to anyone not using an editor especially designed for d.

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

Agreed. Again, Phobos sources will be studied and emulated by many. I  
don't want d to earn the reputation of a language requiring ten  
unittest lines per payload line.



> -Steve
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos