Date/time class changes to handle extended date ranges
lists at astrojar.org.uk
Mon Feb 20 02:24:23 GMT 2006
On Sunday 19 February 2006 23:42, 'R.F. Pels' wrote:
>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.
I don't believe that it's either a hard-and-fast rule that Q and K classes have
to have exactly the relationship you describe, and nor do I think that it's
misleading if a class is properly documented. You have your opinions, I disagree.
If other people whose opinion carries weight agree with you, I am quite happy to
go along with that and change the name. But until then, I propose to use KDate
and KDateTime as the simplest, most straightforward names for the classes.
KAlarm author & maintainer.
More information about the kde-core-devel