On Sunday 19 February 2006 23:42, R.F. Pels wrote:
> On Sunday 19 February 2006 23.46, David Jarvie wrote:
> > 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
> 	}

I think you missed David's point. The equivalent code when using QDate only 
is:

qdate = some_qdate_i_made_earlier;
if (qdate.isValid())
{
  // No problem here
}
else
{
  // Exactly the same problem as in your code.
}

It's basically a lot like moving from using a 32-bit integer to a 64-bit 
integer. If all the relevant code treats it as a 64-bit integer, then you get 
extra precision. If you need to give the number to some code that expects a 
32-bit integer, you've gained nothing over using a 32-bit integer all along, 
but *you've lost nothing either*. And that's the real point, as far as I can 
see.

One case where I can see this causing a problem is if you are getting a KDate 
from the user, which you're going to pass to some API which expects a QDate. 
Since you used KDate in your GUI (or whatever), your validation code will 
most likely do the wrong sort of validation. The solution here is simple and 
obvious: you don't actually want a KDate (since that's not what's wanted 
downstream), so don't use one, or at least fix your validation code so it 
only accepts dates you can handle!

Apart from the clearly-necessary change to the behaviour of isValid(), KDate 
sounds like it is a drop-in replacement for QDate in the same way that a long 
long is a drop-in replacement for an int.
-- 
Thanks,
Richard