Date/time class changes to handle extended date ranges

[David Jarvie]

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
>>> error.
>>
>> 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
>	}
>	else
>	{
>  	  // 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.

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