I'd love to have a TimeSpan in Druntime, if nothing else. Thread.sleep() currently takes a long (if I remember correctly), which is just horrible.
On Jan 19, 2010, at 9:58 AM, Andrei Alexandrescu wrote: > (Adding the Phobos list.) > > I think this is a great initiative. It would be great if you implemented > better time handling. The design is good, many APIs separate TimeSpan from > Time. Note that Walter and I got burned in the past by an API proposal that > added many types but not a lot of functionality, so expect some scrutiny :o). > > > Andrei > > Steve Schveighoffer wrote: >> Andrei, >> Reading your chapter on concurrency reminded me of one of the deficiencies I >> saw (and fixed) in Tango long ago. It was my first contribution to tango -- >> Time handling. >> Specifically, Tango used 2 different types to represent time (a double and a >> DateTime structure), and each type could either represent a length of time >> or a point in time. Such things led to lots of confusion (is this a length >> of time or a point in time? Does this function need a timeout or a date?). >> I fixed that (although Kris still insisted on using straight double values >> in tango.core) to use two specific structs for time -- TimeSpan and Time. A >> TimeSpan value represents a length of time. A Time value represented a >> point in time. Both structs used 100-nanosecond increments encoded as a >> long value (the same resolution and data sizes used on Windows), with 0 >> being equivalent to the Gregorian epoch (1/1/0001). >> What was very nice about the dual-struct relationship is you could define >> things that would otherwise allow nonsensical operations and parameter >> types. For example, subtracting two Time structures yields a TimeSpan. You >> can add two TimeSpan structures and a TimeSpan to a Time structure (yielding >> another Time structure), but you cannot add two Time structures together. >> Underneath, the code simply is dealing with adding and subtracting longs, so >> the inliner/optimizer should reduce down to the same. >> I'm wondering if Phobos could use such a standard set of structures? I >> would be willing to re-implement them for Phobos. I wrote much of the code, >> but I did start from a previously existing Time structure that represented >> both time spans and points in time. However, the code is so simple and >> fundamental I don't think it would be considered copying if I reimplemented >> it from scratch. To go along with this was a Calendar hierarchy which gave >> more meaning to the points in time (i.e. dates, adding/subtracting a number >> of months, etc). The Calendar hierarchy I think was a little over the top, >> I think Phobos can do well with just implementing extended Gregorian, >> leaving extra calendar types for external libraries. >> What reminded me of it is your receiveTimeout function -- how would this >> look: >> receiveTimeout(TimeSpan.seconds(1), ...) >> or maybe have a global function: >> receiveTimeout(seconds(1), ...) >> What I've found is that it's much simpler to use, you don't have to think >> about the scale for different methods (is this milliseconds or >> microseconds?) and you no longer have to document things like this: >> int timeout = 1000; // in milliseconds >> This is also similar to .NET which has extensive support for TimeSpan etc. >> types in all their libraries (sockets, threading, etc.) >> Does this sound like something you'd be interested in? I know Sean was all >> for it when I proposed it for Tango. >> -Steve >> > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
