On 10/10/10 9:23 CDT, Jonathan M Davis wrote:
On Sunday 10 October 2010 06:43:59 Andrei Alexandrescu wrote:
Here's an unrelated suggestion that might simplify things a fair amount:
drop the "months" and the "years" durations. They are the only ones that
are irregular. Then you have only one duration type that's always
precise and you can drop the interval type. If someone wants to figure
out e.g. the number of months between two dates, we can provide specific
functions.
It's not an altogether bad suggestion, but I think that it limits the
expressiveness of the library. For instance, if you wanted to iterate over a
range of Christmases, you would need to be able to indicate that you wanted a
year between each date that you were iterating over. That is, each date in the
range would be 1 year later than the previous one. You can't indicate that with
a duration of days, because once you hit a leap year, you'll get December 24th
instead of December 25th. You need to be able to indicate years.
In this example I'd iterate over years and construct Date(year,
Month.dec, 25) on the fly. So that's not a compelling example, but I'm
not saying one doesn't exist.
Now, we _could_ have addXXX functions for months and years and use durations for
everything else. It's a little bit awkward, but it would solve the range issue I
just mentioned and still allow for the adding of months and years. The one
problem that remains is that that makes it impossible to do something like
Dur.months(5) + Dur.days(3) to indicate a duration of 5 months and 3 days. And
creating a range function which iterates over successive dates which are 5
months and 3 days apart would be much harder because you would have to use both
the add function and a duration to do it.
I think we're safe to drop things like Dur.months(5) + Dur.days(3). I
can hardly think of a use case for such, and I think it's much better to
accommodate them in other ways - e.g. allow addMonths to dates. (There
would be no addDays because days are regular durations so + and +=
should suffice. Yay!)
Eliminating MonthDuration and JointDuration in favor of simply having
HNSecDuration simplifies a fair bit of code, but it makes it very hard to mix
months and years and anything smaller anywhere. So, it's tempting, but I'm not
entirely sure if it's a good idea or not.
Let's enumerate what we stand to lose.
By having duration creation be entirely by functions without requiring the
programmer to really have to care about the types of the durations, for the most
part, you manage to be able to mix months and smaller units without causing
problems for the programmer. It _does_ complicate the library itself, and it is
certainly possible for it to cause problems for the user (like if they don't use
auto or if they try and pass a duration to a function that they write), but it
manages to avoid most of them.
It also complicates users' lives. One thing I've learned by working on
Phobos is that people _do_ look at and judge library code. And clearly
API sizes are an issue. Again, enumerating what we stand to lose and
possibly serving that through specialized functions might be the easiest
way to go.
So, I'm a bit torn on the issue. The extra complication is annoying, but if we
go for a single duration type (or two if you count TickDuration), there's
definitely code which gets simplified. On the other hand, other code becomes
harder to write.
Let's see which, and let's see how we can improve that without
aggravating anyone.
In terms of the code that I've written which uses durations
(which is primarily the unit tests), I think that the current solution generally
works quite well, but then again, I understand the issues of MonthDuration vs
HNSecDuration and am not confused by the multiple duration types. It's likely to
be more confusing for someone who hasn't dealt with it before. On the other
hand, if you're typically using durations in time code and you suddenly need to
deal with months or years, the lack of ability to create durations of months or
years would also be confusing and potentially frustrating.
My suspicion is that there are very few users who are sophisticated
enough to manipulate months/years durations (with all the wierdnesses),
yet too simple-minded to code their way out of a paper bag.
So, I'm not really sure what the best solution is. For the most part, I like it
how it is, but it certainly isn't ideal (then again, "ideal" isn't really
possible due to the variable number of days in months and years). I'll have to
think about it, and I really don't know what the average programmer would
prefer, or how limiting it will be to the not-so average programmer who is
really trying to leverage the library if they can't have durations of months or
years.
Again, the action item is to find realistic use cases.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
