[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 17:31:14
Message-ID: CACcA1RqZgUEuFBKRVbK0xa-UcmMwYs2shPvbWs_HjL-JabRnCw () mail ! gmail ! com
[Download RAW message or body]
On Mon, Apr 27, 2015 at 10:17 PM, Christian Mollekopf
<chrigi_1@fastmail.fm> wrote:
> Hey,
>
> KDateTime used to have a date-only functionality, that QDateTime is
> lacking. The problem with that is that we need to find a new solution
> for interfaces that allow to set/get either QDate or QDateTime.
>
> One such interface is KCalCore::Event::start(). For the sake of
> discussion getters are more interesting, because a simple overload is
> not possible. I see the following possible solutions:
>
> 1. add isDateOnly functionality to QDateTime
> 2. Overloads with different names: QDate startDate(), QDateTime
> startDateTime()
> 3. Overloads using templates: T start<T>()
> 4. QVariant that can contain either QDateTime or QDate: QVariant start()
> 5. boost::variant that can contain either QDateTime or QDate:
> boost::variant<QDate, QDateTime> start()
>
> Given that this should be a fairly common porting problem (at least in
> the PIM realm), it would be nice to have a standard solution for it.
>
> Opinions following:
> 1. I'm not sure whether it semantically makes sense to have a QDateTime
> without a time. It would make sense to have a PointInTime with higher or
> lower accuracy though.
> 2. Not a solution, but a workaround.
> 3. Better than 2., but not by much.
> 4. Would be pretty good IMO, but unfortunately leads to an unexpressive
> interface (because QVariant can't be parametrized with valid values).
> 5. boost::variant solves the problem of 4., and is header-only, but I'm
> not sure to what extent boost is accepted in interfaces?
>
> I think the variant solutions are actually not that bad, semantically,
> but QVariant seems a bit useless for a case like this.
>
> Any ideas or opinions?
>
> Cheers,
> Christian
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 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.
Aleix
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic