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