Date/time class changes to handle extended date ranges

[R.F. Pels]

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 at tiscali.nl       http://home.tiscali.nl/~ruurd