Proposal for custom time string formatting in std.datetime

[Jakob Ovrum]

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