www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Time to split up std.datetime into a package?

reply 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
Jun 20 2013
next sibling parent 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
Jun 20 2013
prev sibling parent "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
Jun 20 2013