Date/time class changes to handle extended date ranges
ruurd at tiscali.nl
Mon Feb 20 00:33:21 GMT 2006
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
> 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
More information about the kde-core-devel