On 4/5/13 11:17 AM, Jonathan M Davis wrote:
On Friday, April 05, 2013 13:13:29 Chad Joan wrote:
On 04/02/2013 10:44 PM, Andrei Alexandrescu wrote:
I think it leads to writing less repetitive unittests.
If we did datetime all over again, I'd give a budget of 2000 lines for
all functionality. I bet the solution would be better.
Andrei
My problem with datetime is that it is too monolithic. I really wish it
was split into about 3 different modules. This is frustrating from a
user-perspective. The docs for that thing can easily make someone's
eyes gloss over.
If you split it up, then the LOC per module would become smaller too, as
a side-effect.
If/Once some variant of DIPs 15 or 16 is implemented, we'll be able to
transparently turn modules into packages - making the package have the same
name as the old module and split what was in the old module across multiple
modules in the new package. Code will then work exactly as before, importing
the package as it were a module but allowing you to import the modules in the
package directly in new code if you want to. Then we'll be able to split up
larger modules like std.algorithm or std.datetime if we want to - without
breaking anyone's code.
Once that's available, I have every intention of splitting up std.datetime
into separate modules, but doing so before that would break code, which I
don't want to do.
- Jonathan M Davis
I believe it's really not a module issue at all, but a doc issue. The
two are directly tied today, but I have _no_ problem with importing the
module and using it as is. Yes, it's large in terms of lines in the
file, but really, who's affected by that and how often. Few and seldom.
Breaking it up just because of docs is like ripping a book into 10
books just because you want to only carry one chapter around.
