Date/time class changes to handle extended date ranges

[R.F. Pels]

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.


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