[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Alternative to QDateTime::isDateOnly ?
From:       Aleix Pol <aleixpol () kde ! org>
Date:       2015-04-28 22:33:03
Message-ID: CACcA1Rpp1_Oio=pVZnVT=g8Y7Gyu7tFwVs7HBLRYa_n=+DauGQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, Apr 28, 2015 at 10:11 PM, Christian Mollekopf
<chrigi_1@fastmail.fm> wrote:
> Hey Aleix,
>
>>
>> What about considering the port to be like:
>> QDateTime().time().isNull()?
>>
>> Even QDateTime::isValid documentation mentions that the date and the
>> time need to be valid, therefore the time can be invalid.
>>
>> With that assumption, I'd say we could even implement
>> QDateTime::isDateOnly() or similar.
>>
>
> I appreciate the pragmatism of that approach, but I just consider an
> interface
> that returns an invalid QDateTime fundamentally broken (tm).
> I mean, that would be like the first thing I'd check in a unittest, and
> the behaviour would IMO be completely unexpected.

Rock and roll! \\nn//

Let's not do it then. :)

>
> I may be a bit extreme that way, but QDateTime::isValid() would be a
> blocker
> for the isDateOnly() functionality IMO.
>
>> I would most certainly not go into template stuff (i.e. 3, 4 and 5) 2
>> looks ok but if we get to add the API in Qt, we'll get to port things
>> much more easily.
>
> I agree that the Qt solution would be the easiest, but why would you not
> use the template solutions?
> They actually seem to be the cleanest to me.

- value<T>
Using templates when you know the 2 types it will have is not better
than just making both methods.

- variant<Something>/QPair<>
It's hard to read the code afterwards.

What about having a new class (In KCoreAddons? KCalCore?) to replace
KDateTime in PIM?

Something like:
class Occasion
{
QDateTime dateTime() const;
QDate date() const;
bool isAllDay() const;
}

HTH,
Aleix
[prev in list] [next in list] [prev in thread] [next in thread]