KCalendarSystem et al.

[John Layt]

Hi,

I promised a mail of what to do with the KCalendarSystem, and finally here it 
is.

Let's quickly recap.  The plan is to switch to using native Qt classes and api 
for all locale, date and time zone functionality.  This is dependent on my 
adding calendar and time zone support to Qt.  Qt decided they wanted this done 
using ICU so I'm coding that and have about 4 weeks left to make it happen for 
5.1.  If I pull it off, then KLocale, KCalendarSystem, KTimeZone, KDateTime 
and related classes will all end up in KDE4 Support to ease porting. If I 
don't then they will continue to exist in wide use for a while longer, but 
possibly still in KDE4 Support so we can make a switch later?

As such we need to limit any changes to ensure we maintain maximum source and 
behaviour compatibility, but still clean the classes up enough to ensure that 
if I fail we have maintainable code for the life of KF5.  The code changes 
required to switch from KLocale/KCalendarSystem to QLocale/QCalendarSystem are 
significant, so most apps will likely take a while to switch, which only makes 
keeping KDE4 compatibility even more important.

So what do I think should change in KCalendarSystem?
* Synchronise date calculations with Qt5, i.e. remove KQDateCalendarSystem
* Synchronise the base class API to match the Qt5 QDate API changes, mostly 
just using qint64 instead of int, etc
* Change the KCalendarSystem public base class to no longer be virtual or have 
derived sub-classes.  This is an artefact of the early days when it was 
thought people would sub-class their own calendar systems, but this really 
didn't happen.  In KDE4 this became a problem as we hadn't reserved more 
virtual slots, so new features couldn't be virtual.  Instead I put the new 
logic into the private class and made that virtual instead.  For KF5 we should 
try remove the virtual from the public base class, remove the derived base 
classes, and have a single public class with a virtual private class that the 
specific calendars are derived from.  This is SC as apps only use 
KCalendarSystem via a factory method.
* Performance optimisations are good but should not affect code 
maintainability or make maintaining BC more difficult.

I could do a review of the API, there are a number of methods I'd like to 
delete rather than just mark as deprecated as they are really internal 
implementation details and are not used elsewhere, or are plain wrong, but 
that's up for debate if it's acceptable.

Thoughts?

John.