Proposal for custom time string formatting in std.datetime

[Jacob Carlborg]

On 2011-12-25 15:31, Jakob Ovrum wrote:
> On Sunday, 25 December 2011 at 14:00:58 UTC, Jacob Carlborg wrote:
>> On 2011-12-25 04:05, zhang wrote:
>>>> On Fri, 23 Dec 2011 02:21:37 -0000, Walter Bright
>>>> <newshound2 at digitalmars.com> wrote:
>>>>
>>>>> On 12/22/2011 11:25 AM, Piotr Szturmaj wrote:
>>>>>> I wish D could support partial modules - partial as analogy to C#'s
>>>>>> partial
>>>>>> classes.
>>>>>>
>>>>>> module std.datetime-unit1;
>>>>>> import std.datetime-unit2;
>>>>>> // dash allowed only in submodules with the same module name
>>>>>> ...
>>>>>>
>>>>>> module std.datetime-unit2;
>>>>>> import std.datetime-unit1;
>>>>>> ...
>>>>>>
>>>>>> // then
>>>>>>
>>>>>> module whatever;
>>>>>> import std.datetime; // as usual
>>>>>
>>>>>
>>>>> I have no idea why anyone would want this. (Is it because the file is
>>>>> too big to fit on a floppy disk?<g>)
>>>
>>> As for big module, my solutions are:
>>> 1) put related modules into a package (or directory)
>>> 2) add a module named all.d into the directory, and this module will
>>> import all the other modules publicly
>>> 3) now just import the *all* module when needed
>>
>> Here we have yet another example of some one who wants to use "import
>> foo.*;".
>
> I agree it would be nice to have a proper way to do this. Providing .all
> modules feels hacky and they need to be manually maintained - it also
> doesn't look as good.
>
> The _really important thing_ to note here is, there are at least two
> kinds of D libraries when it comes to this issue. Some libraries,
> including Phobos, prefer putting a lot of stuff in one module rather
> than splitting it up into a package. But many other libraries prefer
> splitting a library over multiple modules and using the package system
> to tie them together.
>
> Arguing over which approach is better comes down to a wide range of
> arguments, many quite subjective. I do not believe either approach is
> always better than the other. But I do believe it's important not to
> disregard the package approach, because it has advantages and adherents
> as well.
>
> Right now, the language favours the single module approach. When
> packages are used instead, it's clunky to provide a convenient interface
> to the entire library, and it's not very intuitive to look for a ".all"
> module, which could be named anything.
>
> I really like the idea of simply adding "import myPackage;", behaving
> like your average ".all" module.
>
> Doing it this way solves at least three problems: No more clunky
> maintenance of convenience modules, big modules can later be split up
> into a package without breaking any client code, and we don't have to
> worry about a ".all" module for Phobos anymore (which is a suggestion
> that has been on the table several times).

I'm not sure if I like that syntax because you wouldn't be able to tell 
the difference between importing a package and a module. But perhaps 
that's the point. Otherwise I agree.

-- 
/Jacob Carlborg