Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Mon Feb 20 10:18:20 GMT 2006
On Monday 20 February 2006 10.36, Guillaume Laurent wrote:
> > If it is for a part in KDE or Qt that is widely used because it is
> > something very fundamental, yes, it is a big deal. And 'have to write at
> > one time or another' is not a very good argument for not considering
> > giving the classes a proper name. Giving those classes a proper name IS a
> > big deal.
> I agree that breaking the Liskov Substitution Principle is a bad thing,
> but I don't think it applies here.
I think it does apply - especially if the class is meant as a drop in
replacement. If it is not, then the name and the interface should reflect
> QDate already has a 'isValid()' method, so no matter where a QDate comes
> from, you already know that you have to check for it's validity, i.e. that
> boilerplate code of yours has to be written anyway.
That makes it even worse :-(
if (kdate.isValid() == true)
qdate = kdate.convertToQDate();
if (qdate.isValid == true)
// Alrightie! I survived :-)
// Uhoh again!
I think it stinks. If we want an extension of the date range, I think it
should be applied on the Qt level. And I'm not seeing that happen anytime
soon unless we do the patch-qt-song-and-dance :-(
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