Date/time class changes to handle extended date ranges

[R.F. Pels]

On Sunday 19 February 2006 21.24, Frans Englich wrote:

>> 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.

I agree too. I even think that the class should not even offer conversion 
operators because it cannot guarantee errorless conversion to a QDate.

> 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.

They are not bad names per se but they do not fit the general Q->K scheme. If 
there is a disconnect between QDate and KDate - which is the case due to the 
difference in contract - I would prefer if the interface was different and 
the name was such that it does not even remotely imply that it has anything 
to do with QDate. Or it should at least make clear from the name that it is 
somehow an extension. Call it KExtendedQDate for example.

As for KListBox I do not see how it breaks its contract with respect to 
QListBox. The documentation specifies:

	Extends the functionality of QListBox to honor the 
	system wide settings for Single Click/Double Click mode, 
	Auto Selection and Change Cursor over Link.

In other words: I, KListBox, honor the contract that QListBox offers with the
additional restraint that I ADDITIONALLY honor certain system wide settings.

This is the same as an extra contractual clause which NARROWS the scope of the 
contract. If I as a user cannot live with the additional clause, I can use a 
QListBox instead. If one applies the same to QDate and KDate and QDate and 
KDate are similar in interface (same methods etcetera) but the KDate contract 
tells me that the supported date range is LARGER than that of QDate, then 
that is a broadening of the contract, not a narrowing, and the user of KDate 
does NOT have the possibility of falling back to a QDate. That is why ANY AND 
ALL connection between QDate and KDate is inadvisable, including using a 
class name that might imply a connection between the two.

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

I do not have a problem with an implicit conversion from QDate to KDate 
because that can be guaranteed to succeed, even if the QDate is invalid. In 
that case, create an invalid KDate object. No problems there.

-- 
R.F. Pels,  3e Rompert 118,  5233 AL  's-Hertogenbosch,  The Netherlands
+31736414590        ruurd at tiscali.nl       http://home.tiscali.nl/~ruurd