[phobos] datetime review

[Andrei Alexandrescu]

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