Alternative to QDateTime::isDateOnly ?

[Christian Mollekopf]

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
same.

> - 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" [0] 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 ;-)

Cheers,
Christian

[0] http://www.drdobbs.com/cpp/discriminated-unions-i/184403821?pgno=2