Date/time class changes to handle extended date ranges

[R.F. Pels]

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 
rule:

	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
> interface.

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 
inconsistency starts.

> 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