On Friday 05 November 2010 06:06:09 Steve Schveighoffer wrote:
> That sound exactly like what I wanted, thanks!
> 
> BTW, when I said I think std.datetime should use core.time.Duration as its duration type, I meant that in terms of where the Duration type was located, not which implementation should be used.  I guess I didn't really make that clear. Definitely, we should use the most complete implementation.

Well, I figured that that's what you meant, but I'm obviously more partial to using my implementation unless there's something a lot better about the other (especially since so much of std.datetime uses it), but I really do think that what I have is better, and if there's something that needs to be adjusted about it to work better in core.time, then that can be done. Regardless, the suggestion that core.time and std.datetime should use the same Duration type makes good sense. Perhaps if implicit conversions could be easily created, then having two types wouldn't be all that big a deal, but they can't be easily created, and even then, it would still be preferable to have them use the same type if at all reasonable.

In any case, I don't get the impression that core.time needs anything particularly fancy while std.datetime has somewhat more expansive needs, so it makes more sense that the Duration type cater somewhat more to what std.datetime needs while making sure that it does what core.time needs. But for the most part, I expect they need the same thing - it's just that std.datetime needs a bit more.

- Jonathan M Davis

On Friday 05 November 2010 13:11:46 Sean Kelly wrote:
> On Nov 5, 2010, at 1:04 PM, Jonathan M Davis wrote:
> > On Friday, November 05, 2010 07:06:59 Sean Kelly wrote:
> >> On Nov 4, 2010, at 6:43 PM, Jonathan M Davis wrote:
> >>> Looking at core.time, I'd really suggest just moving over std.datetime.Duration to core.time along with TickDuration, FracSec, and the dur!() function for creating Durations, possibly along with some of the helper functions (which I believe are primarily restricted to template constraints).
> >> 
> >> Are there still 4 distinct duration types?
> > 
> > No. Just two. Much as I liked the 4, and I thought that they worked quite well (for the most part, you didn't have to care about the types), pretty much everyone else thought that it was overly complicated. So, I reduced it to two. Now it's TickDuration (which was SHOO's Ticks), which is used when getting the time from the system, and Duration (which essentially was HNSecDuration), which holds the number of hnsecs. It's similar to what you have, but it does have functionality which yours doesn't have to fit in better with std.datetime, and it makes heavier use of templates than yours does. For instance, to create one, you'd use calls like dur!"seconds(5) or dur!"(usecs)(502), and getter functions like seconds are aliases for get - e.g. get!"seconds" - so it's far better suited to generic programming.
> > 
> > I'll try and have a proposed core.time tonight or tomorrow, though it should be noted that it may need further changes based on how the review of the current datetime code goes, even if it seems entirely acceptable on its own.
> 
> I rolled these changes into druntime now because I figure there's plenty of time before the next release to sort out the details, so no rush :-)

Well, it took longer than I expected (primarily due to the lack of access to Phobos functions in core code), but here's my updated datetime with time split out as a proposed core.time: http://is.gd/gSwDv

I ended up moving or copying over a bit more than I would have liked, and there are a few symbols which I had to tack t or T on the front of to make them not conflict with other stuff (even though they were private), but datetime's Duration does now appear to have been successfully split out. I posted the update to the D list as well, though that thread has been pretty quiet.

- Jonathan M Davis