Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Sun Feb 19 17:16:27 GMT 2006
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.
Because everybody knows that KDE is built on top of Qt for a large part, and
the common sense for providing a name for a KDE class that wraps or emulates
an underlying Qt class is to change the 'Q' into a 'K':
QDialog ---> KDialog
QEdit ---> KEdit
etcetera. This implies the common sense that in order to find (part of) the
functionality of a K class, it is often found in the corresponding Q class:
KDialog ---> QDialog
KEdit ---> QEdit
etcetera. Now, all of a sudden we are about to introduce a deviation from that
KDate -/-> QDate
KDateTime -/-> QDateTime
> You see that this will "certainly lead to trouble", I don't, so you have to
> give examples. It's not about specialization(as in inheritance) because the
> classes won't inherit Qt's. And they won't wrap Qt's classes(such as in the
> meaning of a delegation pattern); KDateTime will have a QTime instance
> internally for handling time, but that's not about the class's role or
Wether or not the intended goal is achieved by inheritance or encapsulation is
not important. If it has the same interface as a QDate that implies
compatibility regardless of its inner implementation. Extending the range
breaks that compatibility. If the KDate interface is radically different, it
breaks the Q->K common sense rule.
> 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.
> But this K* proposal does not introduce something new, it only
> stays /consistent/ with existing code and practices.
And that is where the reasoning fails. Extending the range while still
adopting a name that follows the Q->K common sense rule is where the
> 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.
R.F. Pels, 3e Rompert 118, 5233 AL 's-Hertogenbosch, The Netherlands
+31736414590 ruurd at tiscali.nl http://home.tiscali.nl/~ruurd
More information about the kde-core-devel