(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
> 
> 
> 
> 

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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos