Please vote on std.datetime

[Jonathan M Davis]

On Friday 10 December 2010 17:10:05 David Nadlinger wrote:
> On 12/11/10 1:17 AM, Jonathan M Davis wrote:
> > Except then you have to go out of your way to do that. It's no longer the
> > default.
> 
> Well, as the user would explicitly import that module anyway, it's just
> a few extra characters. You could always team up with bearophile to push
> only importing the module name into scope by default though, I guess. ;)
> 
> I personally have one major problem with classes used to fake namespaces
> in datetime – that it's going to be part of the standard library. I
> mean, if you personally prefer classes to the »canonical« approach of
> using modules for grouping related code, that's fine with me, but now
> this is part of Phobos, and I'm pretty sure that some people will ask
> (at least themselves):
> 
> Hey, so there are these neat things called modules in D which are
> supposed to be used for organizing your code, but still they have mixed
> different concepts together in that datetime part of the standard
> library, using classes as pseudo namespaces so things don't get mixed up
> too much – why that?

Well, I'm not the only one to have done it. IIRC, the new std.process will have 
a class that acts as a namespace in it.

What I'm trying to create here are some very specific namespaces which are always 
used. Creating a separate module would make no sense and would make it so that 
you wouldn't actually use the namespace name to access the functions, which 
would defeat the purpose of the namespace in the first place. Other languages 
allow for namespaces within files or modules. D doesn't have such a mechanism, so 
some of us have chosen to use uninstantiatable classes for that in limited 
circumstances. I am by no means arguing that it should be done frequently (quite 
the opposite, really), but I think that the cases that use them in std.datetime 
definitely benefit from it.

- Jonathan M Davis