[phobos] datetime review

[Michel Fortin]

Le 2010-10-11 à 13:19, Jonathan M Davis a écrit :

> On Sunday, October 10, 2010 09:20:31 Michel Fortin wrote:
>> Another option I might propose is to get rid of MonthDuration by using
>> JointDuration instead and rename it to CalendarDuration.
>> 
>> But in my opinion, calendar things like this should simply belong to a
>> separate module. This would simplify the API for those who don't need to
>> deal with the complexities of the calendar.
> 
> That's not an entirely bad idea, but since any types which deal with durations would have to know about CalendarDuration, it wouldn't really help much. And while I completely agree that we want to make the more advanced features not get in the average users way, most of the calendar stuff is built into the types themselves, so you can't really create a calendar module to hold it.

I'm aware that my suggestion doesn't fit very well the structure of your code. Personally, that the calendar stuff is built into the type themselves is what makes me a little uneasy with the current design; otherwise I like this API. But extracting calendar stuff would require rethinking a couple of things, I'm not too sure if it's worth it.

For instance, you say "any types which deal with durations would have to know about CalendarDuration", but you can generally fix that by making the duration responsible for the appropriate convertions. For instance, adding a duration to a timestamp could involve calling a function "duration.hnsecDurationFrom(timestamp)" to convert the duration in hnseconds. HNSecDuration would simply return itself while CalendarDuration would do the conversion based on the given timestamp. And the day someone wants to implement JapaneseCalendarDuration (or any other kind of duration), he'll just have to implement this function on his duration type.

I'm wondering if this can be implemented without too much code.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/