Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Sun Feb 19 19:46:54 GMT 2006
On Sunday 19 February 2006 19.14, Frans Englich wrote:
> Let's skip the metaphors. Can you give a *concrete* example of how it
Use a KDate, fill in an extended value, then convert and pass to a database
>> 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
... 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
> 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
More information about the kde-core-devel