Replacement for KDateTime

[Thomas Lübking]

On Sonntag, 2. August 2015 20:32:43 CEST, David Jarvie wrote:

> Having a date-only attribute in KDateTime is very useful 
> because it allows both date-time and date-only values to be 
> encapsulated in a single class. This avoids having to be able to 
> pass either a QDate or QDateTime or to have a separate flag 
> everywhere this is used, and it allows date-time values to be 
> compared to date-only values using class methods.

Sorry, but I don't follow here.

QDateTime *has* a QDate AND a QTime member.
They can independently be null/invalid.

=> With a QDateTime with invalid QTime member, you *have* a QDate-only QDateTime, agreed?

The "problem" would be that

if (kdt.isValid()) {
   if (kdt.isDateOnly())
      foo();
   else
      bar(); 
}

turns into:

if (qdt.date().isValid()) {
   if (!qdt.time().isValid())
      foo();
   else
      bar(); 
}

right?
Doesn't look that horrible.

-

Now, it however seems to me you'd like to have a flag "butIgnoreTheTime" that hints for some client code behavior, ie. you actually want to carry valid date and time in the object, but in addition have a flag _in_the_object_ to effectively pass a parameter to a function to do something different with this object.

Is this actually correct?

=> That frankly sounds like a bool trap on steroids.

You've an object flying around that may or not have set this flag for some™ ominous reason in the past for some™ function call and different modules might have different requirements for this flag for different reasons... ewwww.


Imo, if you want to embed instructions on what to do with the object inside the object, they should rather be not the least ambiguous, ie. provide dynamic properties or such.

But, ultimately, function parameters belong into the function parameter list - not into object attributes (yes, "unless you're doing some hardcore optimizations or dirty side-channel communication hacks")

Cheers to my 2¢,
Thomas