• Andrej Mitrovic (9/9) Jun 20 2013 Now that DIP37[1] is implemented (unless there are any bugs left with
• Jacob Carlborg (5/9) Jun 20 2013 Would it be logical to split the date and time functionality into
• Jonathan M Davis (6/16) Jun 20 2013 No. The only type which only involves time is TimeOfDay. It might make s...

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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?

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

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

That should cut down on line numbers significantly.

[1] : http://wiki.dlang.org/DIP37

Jacob Carlborg <doob me.com> writes:

On 2013-06-20 17:55, Andrej Mitrovic wrote:

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

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

Would it be logical to split the date and time functionality into 
separate modules?

-- 
/Jacob Carlborg

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Thursday, June 20, 2013 21:34:05 Jacob Carlborg wrote:
 On 2013-06-20 17:55, Andrej Mitrovic wrote:
 As a first step I recommend we separate out unittests into a test module:
 
 std\datetime\core.d -- the actual implementation, name it whatever you
 want
 std\datetime\package.d -- package module
 std\datetime\test.d -- unittests

 
 Would it be logical to split the date and time functionality into
 separate modules?

No. The only type which only involves time is TimeOfDay. It might make sense 
to put it in its own module if each time point type is put in its own module, 
but it's a very small portion of the overall code, so splitting it off by 
itself doesn't do much to the module's size at all.

- Jonathan M Davis