What's missing from Phobos for Orbit (package manager)

[Jonathan M Davis]

On Friday, February 15, 2013 11:10:04 Jacob Carlborg wrote:
> On 2013-02-15 10:14, Jonathan M Davis wrote:
> > Tests are over half of it, and the documentation is probably around half
> > of
> > what's left after that, and those tests are critical. As simple as much of
> > the code is, it's ridiculously easy to get stuff wrong when it comes to
> > corner cases. And it's doing a _lot_ more than getting the time. So, for
> > the most part, I think that it merits being as large as it is. It's the
> > fact that it's all in one module that's the problem (and it was actually
> > split in my original proposal, but I split it badly, and I was told to
> > put it back together again. It also changed quite a lot over the course
> > of the review).
> > 
> > I _would_ like to split it up though. But I'm not going to do it until
> > some
> > variant of DIP 15 or 16 is implemented so that it can be split up in place
> > without breaking any code.
> 
> The easy solution would be to have the tests in its own module, in its
> own directory structure. But that's a no no since apparently "tests in D
> are supposed to be inline".

And it would make maintenance harder. I find that it's extremely valuable to 
have the tests right after the functions that they're testing. It's extremely 
annoying that you can't generally do that with templated types (because then 
the tests are instantiated with the template). I'd hate to put the tests 
separate from the functions that they're testing. And I don't find that the 
size of the file is really a problem. The problem is the size of the generated 
documentation. _That's_ what really needs to be split up, and if the generated 
docs were to be split without changing std/datetime.d, that would solve 95% of 
the problem. Having the various types organized into sub-modules would help 
somewhat with maintainence, but not a lot. I use vim's search capabilities for 
finding everything in source code normally anyway. Scrolling is way too slow in 
comparison even for small modules.

I know that you like the idea of separating the tests from the code, and maybe 
that works well for you, but that just doesn't work well for me. I very much 
like the fact that the normal place to put unit tests in D is right after the 
function being tested.

- Jonathan M Davis