[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: Date/time class changes to handle extended date ranges
From: Guillaume Laurent <glaurent () telegraph-road ! org>
Date: 2006-02-20 11:04:18
Message-ID: 43F9A232.1070001 () telegraph-road ! org
[Download RAW message or body]
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic