About the Expressiveness of D

[Brad Roberts]

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.