On Wed, Apr 29, 2015, at 12:33 AM, Aleix Pol wrote: > On Tue, Apr 28, 2015 at 10:11 PM, Christian Mollekopf > <chrig...@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