(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
