Date/time class changes to handle extended date ranges

[Inge Wallin]

On Monday 20 February 2006 00.42, R.F. Pels wrote:

> 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
> 	}
>
> Again: if there is a disconnect between the implication of the name KDate
> and its real functionality, don't call the class KDate. If the new class
> cannot guarantee conversion without error, don't offer the conversion. It
> confuses the people that are going to work with that class and draw a
> couple of conclusions based on among others the Q->K convention.

Frankly, I don't get your problem.  KDate is an *extension* to QDate, i.e. it 
can do more. If you are using KDate in your program there is no reason to 
ever convert it to a QDate since you have KDate available.  If you don't use 
KDate, you won't get the conversion problem ever.

	-Inge

-- 
Inge Wallin               | Thus spake the master programmer:               |
                          |      "After three days without programming,     |
inge at lysator.liu.se       |       life becomes meaningless."                |
                          | Geoffrey James: The Tao of Programming.         |