Date/time class changes to handle extended date ranges

[Frans Englich]

On Sunday 19 February 2006 19:35, R.F. Pels wrote:
> On Sunday 19 February 2006 19.00, David Jarvie wrote:
> > I wasn't aware that there was any such _rule_. It may well be that it's
> > frequently done like that, but there's no reason that I can see to do it
> > slightly differently if it's useful.
>
> I don't think it is a hard rule. It is more a convention in determining the
> name of a corresponding K class if any exist. As a matter of fact I myself
> would be very carefull not to break that convention - especially in a case
> where the contract of an underlying class is extended such as in this
> proposal.
>
> > How awful! Now dates outside QDate's range will work! That will break
> > lots of applications, I'm sure.
>
> Yep. For example in those parts of Qt where a QDate is used such as the
> database classes. Drop in a KDate and there is a disconnect. Use a value
> outside the range offered in the QDate contract and there is a conversion
> error.

Ok, this is a point I can buy, I think this database argument(and similar 
ones) applies. That's the reason why I questioned the casting operators, 
because they add implicit conversion between the types. I think this is 
simply solved with explicit constructors, and not having the conversion 
operators. I agree that QDate/KDate cannot be mixed, and that's why the line 
must be well separated. But that's only my view of it.

However, I still see no sense in that KDateTime/KDate would be bad names. I 
don't see how KDateTime breaks its "contract" more than KListBox does.

Do you see any other problems than those which are solved by having explicit 
constructors and no casting operators?


Cheers,

		Frans