Date/time class changes to handle extended date ranges

[R.F. Pels]

On Sunday 19 February 2006 19.14, Frans Englich wrote:

> Let's skip the metaphors. Can you give a *concrete* example of how it
> breaks? 

Use a KDate, fill in an extended value, then convert and pass to a database 
routine. Oops!!!

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

If that is the case, adding KDate and/or KDateTime in the fashion of the 
proposal makes it worse.

> The convention is really "a K* class is a Q* class with some 
> modification/extension". 

... to be able to use it in the KDE framework in a way that makes sense.

> KDateTime is exactly like QDateTime with the difference of the range; 

... which is why it should NOT BE FOLLOWING the same naming strategy. Naming 
the classes KDate and KDateTime creates expectations that cannot be made 
true.

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

Hah. In that case I would be very much opposed to adding conversions from 
KDate to QDate if there is the possibility that one creates an invalid QDate 
without being able to detect that in an easy way. 

My conclusion is that there is a disconnect between KDate and KDateTime on one 
side and QDate and QDateTime on the other side. This disconnect should be 
reflected in the names of the K-classes and that is why KDate and KDateTime 
are not the right names for those classes.

-- 
R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd at tiscali.nl       http://home.tiscali.nl/~ruurd