Date/time class changes to handle extended date ranges

[Frans Englich]

On Sunday 19 February 2006 17:16, R.F. Pels wrote:
> On Sunday 19 February 2006 17.45, Frans Englich wrote:
> > I don't follow you. As pointed out by Jarvie, KDateTime is new, it's one
> > or two months old and therefore cannot cause a porting effort. Second,
> > these classes will closely mimmic QDate/QDateTime's APIs for all the
> > usual reasons. Essentially, the only difference is the range. I don't see
> > how this "depature from QDateTime" should hinder its acceptance.

[...]
> > It's not that controversial. The only change is in range. They still
> > deals with Gregorian ranges, and it's about dates and times. E.g, we're
> > still driving a car(breaking, turning, etc), the only change is that
> > we've bumped the max-speed. The classes have new names(K*), and they are
> > not members of QDate/Time's class hierarchy. I don't see the trouble.
>
> I do. An unsuspecting developer applies the Q->K common sense, drops in
> KDate as a QDate replacement and all of a sudden things break. In that case
> - to extend your car example - the unsuspecting driver stepped into a car
> that all of a sudden has a top speed that is ten times higher, puts his
> foot on the pedal and has an accident.

Let's skip the metaphors. Can you give a *concrete* example of how it breaks? 
So, 1) the user is aware of the extended range and uses KDateTime for that 
reason; 2) It breaks..? How does it break for the user? Even if the user 
decides to use KDateTime with no apparent reason, how does it break?

[...]
> > As I see it, the default calendar system is already adopted; what we need
> > is an extended gregorian range.
>
> Which should be reflected in the class name.

That's not consistent with kdelibs. We have QListBox/KlistBox, 
QMainWindow/KMainWindow, QListView/KListView, *etc*. If you want to push the 
idea that class names in kdelibs should specifically name what it does, you 
got plenty to do in current trunk. The convention is really "a K* class is a 
Q* class with some modification/extension". KDateTime is exactly like 
QDateTime with the difference of the range; such a difference is ok, 
considering how the existing classes are(KMainWindow, etc).

Also, the design of a class should not be judged in isolation, but considered 
in context of the API it is part of. That it is consistent with its 
library/framework.


Cheers,

	Frans