Le 2010-10-11 à 23:12, Jonathan M Davis a écrit : > On Monday 11 October 2010 19:46:15 Michel Fortin wrote: >> 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. > > Once you deal with any kind of date, you have to deal with a calendar, since > all > dates are specific to a calendar.
I disagree. A date can be expressed using different calendars, but can also be stored as an interval since a reference date (like the UNIX epoch). With your main storage format calendar-agnostic you can easily convert back and forth to different calendars-specific formats. Also, if you're dealing only with time -- like calculating the time elapsed between two time points -- then you don't need any calendar unless you plan to display that elapsed time in months or years. And of course I never meant that Phobos should provide more calendars than gregorian. That said, it'd be good if it its gregorian implementation could be used as a base to implement other calendars. -- Michel Fortin [email protected] http://michelf.com/ _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
