[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Date/time class changes to handle extended date ranges
From: "R.F. Pels" <ruurd () tiscali ! nl>
Date: 2006-02-20 10:18:20
Message-ID: 200602201118.21541.ruurd () tiscali ! nl
[Download RAW message or body]
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
that, IMHO.
> 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 :-)
}
else
{
// Uhoh!
}
}
else
{
// 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@tiscali.nl http://home.tiscali.nl/~ruurd
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic