Date/time class changes to handle extended date ranges

[David Jarvie]

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

I wasn't aware that there was any such _rule_. It may well be that it's 
frequently done like that, but there's no reason that I can see to do it 
slightly differently if it's useful. In any case, as far as the class 
interface goes, it virtually IS the same class, just with an extended range. 
The internal implementation of any class is not something that users should 
be concerned with - it's the interface that counts.

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

How awful! Now dates outside QDate's range will work! That will break lots of 
applications, I'm sure.

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

We're using the Qt convention here.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html