Alternative to QDateTime::isDateOnly ?
chrigi_1 at fastmail.fm
Tue Apr 28 23:57:18 BST 2015
On Wed, Apr 29, 2015, at 12:33 AM, Aleix Pol wrote:
> On Tue, Apr 28, 2015 at 10:11 PM, Christian Mollekopf
> <chrigi_1 at fastmail.fm> wrote:
> > 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.
It avoids encoding the type into the name, but yes, it's essentially the
> - variant<Something>/QPair<>
> It's hard to read the code afterwards.
I don't find a "variant<T1, T2>" hard to read.
> 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;
Definitely a good suggestion in line with John's Duration.
What I like about the "discriminated union"  approach is that it
solves pretty much the same problem,
using a more generic solution.
The only good argument I'd see for an Occasion class would be if it
offered additional helpers that are useful
to both date-only and date-time occasions. I.e. a date() accessor, that
returns the date of either date-time or date.
Sooo.... I'm still not entirely sure, but something similar like
boost::variant (a "discriminated union"), doesn't seem like the worst
idea, but something like Occasion is not that far off either. I'll sleep
over it again ;-)
More information about the kde-core-devel