On Tuesday 23 Aug 2011 10:16:08 [email protected] wrote: > So can we do one API for all calendaring systems? If yes, we should most > probably use that fact.
CLDR/ICU does. OSX does. Windows does. No reason we can't :-) > I do agree with Thiago that QDate should be really just a mathematical > representation of a Date. At maximum have some support to convert to > gregorian dates. > > How about a QCalendar class that takes the System as an enum? If we can > use a common API, one class with an enum for the system sounds best to me. > Having separate classes for each calendar sounds suboptimal for some > reasons: > > * I'd also like the class to be a simple value based class. That conflicts > with the concept of a virtual base class. > * A virtual base class also adds the requirement of having factory methods > to get to the right system. Not very nice in terms of usability. > * A QHebrewCalendar etc. means the app developer will hardcode the > calendar used. In many cases the app needs to be flexible because the end > user chose the calendar system, so this will not work very well. Yes, fully agree with all 3 points. Looks like we have a clear external model then. > One big switch, or a private class with virtuals are both fine. I don't > know enough about how difficult each approach would be to maintain, but in > the end this is then an implementation detail we can change at any time in > the future. I'll code up a big switch first, most calendars have only a couple of small differences so most methods won't evem switch, but some like Hebrew take a lot more code so will probably need a virtual just to keep it tidy. For methods which just return a variable, would you prefer a big switch with hard-coded values, or a static look-up table? > No. Let's keep the concept of a date and it's representation to the user > separate. We're doing the same in QString now because doing implicit > conversions to a locale/user dependent format has given us many hidden > bugs before. OK, teach devs that QLocale is the place to go to get the user representation, QDate and QCalendarSystem are just a container and a mathematical converter. > >We could decide to use CLDR everywhere. What arguments do we have to > >using the > >Windows API for calendars? What calendars does it support? What if it > >lacks > >some API we need or some calendar we need? > > Let's please not go into using platform dependent code (or integrating > with it) for the moment. Using CLDR makes all of the code 100% cross > platform and thus a lot easier to test. Yes, CLDR is the first target to get the API right. This also should match with OSX who implement support using CLDR. After that we can worry about Windows quirks. > To sum it up, I'd prefer one value based QCalendar(System) class without > virtuals. It contains a Julian QDate and an enum for the system. Ah, so you are thinking that each QCalendar(System) instance actually holds a specific date instance rather than just being a calculator wrapper to convert a QDate? So really a QLocalDate or QCalendarDate? John. _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
