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.

On 04/02/2013 08:01 PM, Walter Bright wrote:
> On 4/2/2013 4:55 PM, Jesse Phillips wrote:
>> I usually find the build in unittests to cause more skew since those
>> are counted
>> as LOC.
>
> Often, in pulls for D, the LOC of the unittests exceeds the LOC of the fix.
>
> I'm inordinately pleased with how well unittests have become embedded in
> our D culture.

I think this has made me a much better programmer.  And it did so a long time ago.  Big win!

On Fri, 05 Apr 2013 13:13:29 -0400, Chad Joan <chadjoan@gmail.com> wrote:

> 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.

What if the docs were split up?

E.g. http://vibed.org/temp/d-programming-language.org/phobos/std/datetime.html

-Steve

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

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.

On Friday, April 05, 2013 14:36:07 Brad Roberts wrote:
> 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.

To some extent, I agree. I'm quite able to maintain it as one module (though to be fair to anyone arguing that it should be broken up for maintainibility - as sometimes happens - it's large enough that if large portions of it get changed, you can't see the diff on github). I'm not sure that it would _hurt_ maintainibility though to break it up. And I know exactly how I'd break it up if I were to break it up, and it would break up quite cleanly, I think. The main reason that it's not broken up in the first place is that I did a horrible job of breaking it up when I first introduced it, and everyone's reaction was that it should just be one module (the code has changed quite a bit since then though, so breaking it up would be much easier now).

But regardless, with ddoc, breaking up the module would be the only way to break up the documentation, so we're kind of stuck in that regard (though if we start using ddox for dlang.org, that does change things).

- Jonathan m Davis