Time to split up std.datetime into a package?

[Jonathan M Davis]

On Thursday, June 20, 2013 17:55:37 Andrej Mitrovic wrote:
> Now that DIP37[1] is implemented (unless there are any bugs left with
> the implementation), is it time we split up std.datetime into its own
> package?

I'll get to it, but if you'll notice, bugs keep getting fixed on DIP37, so I'm 
not sure that jumping on it right away is a good idea. But I'll probably start 
on it this weekend.

> As a first step I recommend we separate out unittests into a test module:

I completely disagree with that approach. It's _much_ easier to maintain tests 
when they're next to the functions that they're testing (which is why testing 
templated types suck - you can't have the tests next to the functions unless 
they're tests intended for every template instantation). It's also harder to 
test private stuff properly if the tests aren't in the same module.

> std\datetime\core.d -- the actual implementation, name it whatever you want
> std\datetime\package.d  -- package module
> std\datetime\test.d  -- unittests

I have a fair idea of how I want to split it up and have had for some time, 
and it will definitely be more broken up than this. I also see no reason to do 
this in multiple passes as your "first step" remark implies, as if we released 
that way, it would require changing the code multiple times.

Don't worry. I have this under control and will have a pull request for this 
in the relatively near future.

- Jonathan M Davis