Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Sun Feb 19 23:42:24 GMT 2006
On Sunday 19 February 2006 23.46, David Jarvie wrote:
> As Thiago has said, that is exactly the reason for introducing a new class.
And as I say: that is exactly the reason to come up with a better name.
>> Yep. For example in those parts of Qt where a QDate is used such as the
>> database classes. Drop in a KDate and there is a disconnect. Use a value
>> outside the range offered in the QDate contract and there is a conversion
> I still don't see the problem. If you construct a QDate with an
> out-of-range date, you get an invalid QDate, which the database handles in
> whatever way it handles invalid dates. If you use a KDate with a date which
> is out of range for QDate, it is implicitly converted to a QDate which is
> invalid, which is the same as if you used a QDate all along. If you need to
> test whether the KDate is a valid QDate, convert it explicitly to QDate and
> test with isValid().
Yech! Bletch! As I said earlier, that will lead to boilerplate like
qdate = kdate.convertToQDateObject();
if (qdate.isValid() == true)
// No problem here
// You are f****d now. If you want to pass that
// to a method expecting a valid QDate object, go
// and write a bit of extra code to deal with this
Again: if there is a disconnect between the implication of the name KDate and
its real functionality, don't call the class KDate. If the new class cannot
guarantee conversion without error, don't offer the conversion. It confuses
the people that are going to work with that class and draw a couple of
conclusions based on among others the Q->K convention.
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