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
