On Tue, Apr 28, 2015 at 10:11 PM, Christian Mollekopf
<chrig...@fastmail.fm> wrote:
> Hey Aleix,
>
>>
>> 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 appreciate the pragmatism of that approach, but I just consider an
> interface
> that returns an invalid QDateTime fundamentally broken (tm).
> I mean, that would be like the first thing I'd check in a unittest, and
> the behaviour would IMO be completely unexpected.
Rock and roll! \\nn//
Let's not do it then. :)
>
> 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.
- variant<Something>/QPair<>
It's hard to read the code afterwards.
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;
}
HTH,
Aleix
