Date/time class changes to handle extended date ranges
frans.englich at telia.com
Sun Feb 19 18:14:42 GMT 2006
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
More information about the kde-core-devel