Date/time class changes to handle extended date ranges
Guillaume Laurent
glaurent at telegraph-road.org
Mon Feb 20 11:04:18 GMT 2006
R.F. Pels wrote:
> On Monday 20 February 2006 11.29, Guillaume Laurent wrote:
>
>
>> Oh come on, what kind of hair-splitting is that? Just call
>> convertToQDate() directly and check if the result is valid. An invalid
>> KDate will obviously convert to an invalid QDate, so the first check is
>> pointless. And in practice just how often will you need to convert a
>> KDate to a QDate anyway.
>>
>
> Anytime I want to use the Qt database classes to stick the value into a
> database for example.
Granted, but it still won't have to do all those checks you described, just
QDate qdate = kdate.toQDate();
if (qdate.isValid()) { store(qdate); }
which would have been exactly the same no matter how you get the QDate
from, e.g.
QDate qdate = fetchQDateFromSomewhere();
if (qdate.isValid()) { store(qdate); }
same thing.
> Anytime I want to use KDatePicker, KDateTable,
> KDateTimeWidget, KDateValidator, KDateWidget and all the places in KDE where
> a QDate is expected in the interface. A very rough and potentially bad way to
> count them yielded 600+ places in KDE and several applications where it is
> used.
>
I think it's a safe assumption that these classes will be converted to
use KDate. Not a particularly hard refactoring to do, especially if
KDate does derive from QDate, while the contrary would make the
refactoring much more difficult.
More information about the kde-core-devel
mailing list