Please vote on std.datetime

[Jonathan M Davis]

On Thursday 09 December 2010 22:39:39 Sean Kelly wrote:
> Jonathan M Davis Wrote:
> > I would point out though, that as it stands, including std.datetime would
> > require including my time module as core.time (which has been discussed
> > to some extent with Sean, since it was pretty much his idea in the first
> > place that some level of integration should occur there) as well as
> > including my unittests module as something like std.unittests (which was
> > reviewed here on some level, and has definitely been improved from its
> > initial version, but hasn't exactly had overwhelming support). The
> > unittest functions could be integrated privately into std.datetime, but
> > I think that that would be a disservice to the community at large.
> 
> I don't mean to confuse the issue, but since neither of these are necessary
> attributes of std.datetime, they shouldn't be considered as such.  I think
> it's entirely reasonable for the unittest stuff to be made private and
> std.unittests to be created later, or for some code movement from Phobos
> to Druntime to occur later as well.

A valid point, though the bug that makes all templates public would make it 
really annoying in my own code, since then my unittests module would clash with 
std.datetime every time that I included both in anything that I did. And if we 
did either add std.unittests temporarily without adding documentation to the 
site or the distributed zip (so, it's there, but it isn't - kind of like the 
current std.datetime) or if we make the functions private in std.datetime, we'll 
still have to make the decision at some point whether we want to make it an 
actual std.unittests.

I'd also point out that it would probably be a bad idea to have your current 
core.time around just to be replaced by mine shortly thereafter. The change in 
duration type would break all of the code that uses it. Though if Thread.sleep() 
maintains its current API (in addition to the new duration version), then that 
wouldn't be as big a deal (and the old version should probably stay around in 
deprecated form for a while anyway - or at least it should be deprecated once 
the new version of Thread.sleep() is finalized).

So, we do have options, but my version of core.time is critical to std.datetime 
working, and as you pointed out, it's better if we don't end up with multiple, 
incompatible duration types. And while we can put off deciding what exactly to do 
about std.unittests, we're going to have to have a temporary solution if we 
don't make a final (or at least pseudo-final) decision at this point, and we'd 
just be putting off making a final decision (though that's not necessarily a bad 
idea).

Assuming that std.datetime is put into Phobos, I'd suggest just replacing your 
core.time with mine - particularly since yours is so new, and it doesn't provide 
any functionality that mine doesn't. I'd expect the changes to the rest of 
druntime would be quite minimal at this point. And unless we really think that 
my unittests module isn't likely to become std.unittests in any form, I'd 
suggest adding it as std.unittests without putting it in the documentation. That 
way, it's there, and we don't have to make muck with std.datetime to make it 
work without a separate unittests module, but we still have some leeway as to 
whether we keep it around. Other modules have been added in a similar manner 
before.

- Jonathan M Davis