Proposal for custom time string formatting in std.datetime
Jacob Carlborg
doob at me.com
Thu Dec 22 02:40:34 PST 2011
On 2011-12-22 08:58, Jonathan M Davis wrote:
> On Thursday, December 22, 2011 08:34:23 Jacob Carlborg wrote:
>> On 2011-12-22 04:57, Walter Bright wrote:
>>> My first thought is that std.datetime is already very large. Few will
>>> need a custom date formatter, so it should be in a separate module to:
>>>
>>> 1. reduce cognitive load on the programmer
>>>
>>> 2. reduce the overhead pulled in for every program that may want to use
>>> an std.datetime function, but not need custom formatting
>>
>> As I've said several times, std.datetime is way too large and should be
>> a package.
>
> That's the way that it was originally proposed (albeit split in a poor
> manner), and a number of people (particularly Phobos devs) were against it,
> and have been any time that I've suggested splitting out part of it. The fact
> that Phobos has historically shunned sub-packages probably has a lot to do
> with that (though we're starting to have some).
Yeah, I don't get this. Most modules in Phobos are too large, in my opinion.
> To make it a package at this point would probably break a fair bit of code
> unless it were a new package which std.datetime publicly imported, so simply
> making std.datetime a package isn't necessarily a great idea, and there's a
> definite benefit IMHO in being able to just import it all with one import. But
> it's not necessarily unreasonable to create a new package which holds the
> various pieces and have std.datetime import them all.
>
> - Jonathan M Davis
It would break code, but it's better to break it sooner than later.
Seems more and more like D should support importing all modules in a
package, that Java does:
import foo.*;
And yes I know this can be done manually with public imports. I think
it's a benefit to have smaller modules and that a given module is only
responsible for one specific thing.
--
/Jacob Carlborg
More information about the Digitalmars-d
mailing list