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.
> * 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.
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?
> 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.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
