[Development] Views

[André Pönitz]

On Tue, May 21, 2019 at 08:32:07AM +0200, Mutz, Marc via Development wrote:
> 
> By that line of reasoning, the change from
> 
>    Q3Slider *sl = new Q3Slider(0, 100, 50, 10, 1, this);
> 
> to
> 
>    Q4Slider *sl = new Q4Slider(this);
>    sl->setRange(0, 100);
>    sl->setValue(50);
>    sl->setPatheStep(10);
>    sl->setStep(1);
> 
> was also wrong. I now need to check that the calls on the slider are always
> on the same object.

Right, but in this case most of the 'sl' are vertically aligned,
which makes them easily comparible. While that repetition is indeed
a minor nuisance it is more than compensated by the advantage of
having a name for the individual parameter. So overall, the Qt 4
version is much better, despite of the repetition.

This is also not a counter-argument to the STL containedness problem
we were "discussing" as the overall benefit of the Qt 4 version
are *not* due to the repetition, in fact it's there *despite* of
the repetition.

> You are confusing familiarity with simplicity.

I think I can perfectly decide myself what I confuse.

> It's simple that in the STL I can search for a value or a predicate
> condition at the change of just an '_if'. Container::contains(), OTOH,
> is just familiar (from previous Qt versions or other languages).

It's not familiarity, it's the natural question:

  "Container: Do you contain element X?"

vs

  "World: If I were to check all handles starting at something that's
  (sometimes...) a handle to a kind of 'first' element of this container
  (ignoring that you might be unordered, and having an order is something 
  that isn't natural for it), and check all elements refered to by those
  handles whether they equal X, would the algorithm I use return me
  something else that that exceptional (non-)handle that (also...)
  signifies "didn't really find it"?

So no: it's completely the other way round: I *am* familiar with the
Standard Library way to check for containedness, but it's *not simple*
and I am very well aware of the reasons I do not like it: It is a
ridiculously complex and superfluous stanza that leaks implementation
details of the underlying containers (e.g. having some kind of order,
even when the container nominally unordered).

It's something that I do not want to see and nobody should be 
required to use in "normal" code.

> QVector<QString>::contains() is not overloaded on QLatin1String, e.g.
> Std::find(), OTOH, will transparently use the QLatin1String, avoiding the
> creation of a temporary QString. 

And then what? A GUI application waiting for the next key press that
will happen 100ms later will spent 10000 cycles on a 1GHz core for the
"useless" conversion?  There's *quite* some room until this gets even
close to being noticable.

> If contains() turns out to be a performance bottleneck in profiling,
> the user can't do anything about it and needs to go to the universal
> mechanism (std::find).

And if it turns out to be a bottleneck, code can be changed.
This happens, but it does not happen often. E.g. all those "wrong"
usages of QList do not appear in any profile of a Qt Creator run.

> This does not make the API simple to use. Maybe for people coming from other
> languages. It introduces two different ways to do essentially the same
> thing, advocating the ways that only works in a particular corner-case and
> refusing to show the universal way
> (https://doc.qt.io/qt-5/qvector.html#indexOf). But eventually, these
> developers _will_ need to search by a predicate, too, and then they will
> fall back to a raw loop, sometime,

Uhuh... raw loops! And that when you can clutter your code with all
those non-sensical unordered.begin() and unordered.end() iterators.
What a loss of laughableness!

Andre'