Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Sun Feb 19 23:34:31 GMT 2006
On Sunday 19 February 2006 23.41, David Jarvie wrote:
> >It's like converting a "long long" to "char": the compiler may let you,
> >but it'll print a warning. If you want it to shut up because you know
> >better, you have to explicitly cast.
> >This is what classes should do too.
> In this case, the conversion error *would* be detectable, because the QDate
> would return isValid() == false. That wouldn't give a compiler error
> obviously, but wouldn't the isValid() test be sufficient?
Horribilis! Picture this:
QDate qdate = kdate.convertToQDate();
if (qdate.isValid() == true)
// OK no problem here
// Uhoh. Now I'm f****d! How am I going to
// use this in a method that expects a valid
// QDate object???
> The idea of the conversion casts is that KDate could be made a plugin for
> QDate. Remember that the two will be equivalent for all dates in the range
> 1752 - 7999, which covers most uses. Only a few applications are likely to
> hit dates outside that range.
And that is exactly the reason why this class should not be a QDate
specialistion, should not have conversion operators that produce a QDate and
should not have a name that could even remotely give the impression that it
has something to do with a QDate. This class CAN NOT BE a plugin for QDate
because its contract is wider than the contract of QDate.
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