Alternative to QDateTime::isDateOnly ?
aleixpol at kde.org
Tue Apr 28 18:31:14 BST 2015
On Mon, Apr 27, 2015 at 10:17 PM, Christian Mollekopf
<chrigi_1 at fastmail.fm> wrote:
> 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
> 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?
What about considering the port to be like:
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.
More information about the kde-core-devel