On 8/23/11 1:46 PM, "ext Thiago Macieira" <[email protected]> wrote:
>On Tuesday, 23 de August de 2011 11:16:08 [email protected] wrote: >> On 8/22/11 10:13 AM, "ext Thiago Macieira" <[email protected]> wrote: >> >On Monday, 22 de August de 2011 00:13:42 John Layt wrote: >> >The methods have to be inline. We can't repeat the mistake of having >>non- >> >inline Qt3Support methods. >> >> Agree with Thiago. > >This also goes hand-in-hand with the build key discussion: the QT4_COMPAT >is >only for inline methods. To be sure it's working as expected, QT4_COMPAT >should never be enabled while building Qt. > >But it should be enabled in all unit tests. > >> >> Well, for a start we wouldn't be supporting the Mayan calendar, it's >>not >> >> officially or even informally used anywhere and is not part of CLDR >>or >> >> Windows or OSX or KDE support (much as it pains me as a budding >> >> archaeologist to say so :-). >> > >> >Why wouldn't we support it? I used the Mayan calendar as an example of >> >something that is so radically different to provoke the thinking of >> >what's >> >common between calendaring systems. > >I guess we agree on no Mayan; only CLDR calendars. Yes, that's the same as not supporting layouting of egyptian hieroglyphs ;-) > >> * 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. > >Ok, then let's go for a QCalendar or QCalendarSystem that must be >initialised >with an enum. The constructor should default to Gregorian and there >should be >a System or Locale value to match the locale's preferred calendaring >system. Should the default constructor go to gregorian or should it go to the one the user selected as his primary calendaring system? > >Another argument against virtuals is that the lore says virtual calls >defeat >branch prediction and pipelining in the CPU, though I have personally not >done >any benchmarks. I'd say a big switch in each function is preferable. > >> >> I haven't listed the name/format/parse methods as those will be in >> >>QLocale, >> >> they all use the same parser/formatter code excpet the Hebrew >>language >> >>which >> >> has a few special paths. >> > >> >Will that also be true with CLDR? > >John, I still did not get the point you made about Hebrew here. > >> >> Note also that almost everything is hard-coded and accessed via >>methods >> >>not >> >> variables, the only variables are for eras which would move to >>QLocale, >> >>so >> >> there's nothing to copy. >> > >> >Sorry, I didn't understand. How would the era move to QLocale? > >Same. > >> That's quite a bit of copy/paste. But as noted above I don't like this >>too >> much as it would in many cases force the app developer to himself take >> care of every possible calendar system (if the calendaring system is not >> hardcoded for a certain use case, but chosen by the end user). > >Ok. > >> >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. > >I agree. I'm just trying to find the implications. John says Windows has >hundreds of tiny deviations and corrections -- why are they there and >should >we have them? Yes, sounds weird. One would think that calendars are well defined and have a one to one mapping to a day that actually happened (ie. A number in julian). > >> 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. > >It might also have a cached value of era, year, month and day, but I'll >leave >that for John to figure out. Yes, that's an implementation detail. It purely depends on how slow the conversion algorithm is. Lars _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
