[phobos] Split std.datetime in two?

[Andrei Alexandrescu]

On Feb 11, 2011, at 12:34 AM, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, February 10, 2011 15:00:50 spir wrote:
>> On 02/10/2011 11:02 PM, Andrei Alexandrescu wrote:
>>> On 2/10/11 3:44 PM, Don Clugston wrote:
>>>> (1) There has to be a maximum acceptable source file size.
>>>> Personally I start to feel uncomfortable above 2000 lines, and  
>>>> get an
>>>> uncontrollable urge to split at 5000 lines. That's just me, but I
>>>> suggest all modules should be short. And at 35000 lines,
>>>> std.datetime.length> short.max.
>>>
>>> Agreed.
>>>
>>>> (2) Actually, it seems that most of size actually comes because  
>>>> every
>>>> test is written 'by hand'. If they were done as arrays [parameter1,
>>>> parameter2, result]...
>>>> with a loop, they'd be a lot shorter. (I crunched down the
>>>> std.math.exp tests enormously by doing this). Looking at that  
>>>> module,
>>>> I get the feeling that there's been a lot of cut-and-paste.
>>>> It is a little disconcerting if D really cannot write unittesting  
>>>> code
>>>> concisely. If it really needs to be that big, that part of the
>>>> language needs more work; or we need more helper functions. Or  
>>>> both.
>>>
>>> Agreed. People will look at Phobos for inspiration in terms of  
>>> style and
>>> idioms. If they see they're looking at more than 2x the size of  
>>> the code
>>> for adding tests, probably they'd feel intimidated.
>>>
>>> Peeking at std.datetime's unittests, I confirm they are very  
>>> repetitive -
>>> essentially unrolled loops. I just set the bar somewhat halfway  
>>> and saw
>>> the following. I mean come on!
>>>
>>>
>>> Andrei
>>>
>>> assertThrown!DateTimeException(Date.fromISOString(""));
>>> assertThrown!DateTimeException(Date.fromISOString("990704"));
>>> assertThrown!DateTimeException(Date.fromISOString("0100704"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070 "));
>>> [...]
>>
>> I'm interested in this example. I mean how can this happen? What we  
>> would
>> never do in regular (if only because we're lazy, and even copy 
>> +paste sucks
>> for more than a few repetitions), we happily do as soon as the / 
>> context/
>> is somehow different; eg unittests. Just like if unittest were not  
>> code.
>> I've read similar patterns in code by very high-level programmers.  
>> There
>> are even test-case generating tools that produce such code.
>
> Unit tests need to be simple. If they're more complicated, the risk  
> of getting
> them wrong goes up. Also, as Steve points out, determining _what_  
> failed can be
> a royal pain when you try and put something in a loop. Helper  
> functions help
> with that, but it's still a pain.

Not taking one femtosecond to believe that. The hard part is to get  
the unittest to fail. Once it fails, it is all trivial. Insert a  
writeln or use a debugger.

>
> Normal code can afford to be more complex - _especially_ if it's  
> well unit
> tested. But if you make complicated unit tests, then pretty soon you  
> have a
> major burden in making sure that your tests are correct rather than  
> your code.

I am now having a major burden finding the code that does work in a  
sea of chaff.

>
> In the case above, it's testing 5 things, so it's 5 lines. It's  
> simple and
> therefore less error prone. Unit tests really should favor  
> simplicity and
> correctness over reduced line count or increased cleverness.

All code should do that. This is a false choice. Good code must go  
inside unittest and outside unittest.

> The goal of unit
> testing code is inherently different from normal code. _That_ is why  
> unit testing
> code is written differently from normal code.

Not buying it. Unittest code is not exempt from simple good coding  
principles such as avoiding copy and paste.
>

Andrei