[Development] Views

[Mutz, Marc]

On 2019-05-17 19:47, Scott Bloom wrote:
[...]
> Im just going to throw out my 2 bits on this....
> 
> Please don’t underestimate (and Im not hearing Thiago say this) the
> pain, of breaking source compatibility.  Even on Major (5->6) version
> changes.

[...]QCanvas[...]QWebKit[...]

> When the Qt team, decides to make these changes, it hurts a lot of
> developers, who have to justify to their company, I need to spend X
> number of months figuring out a solution, to replicate code that was
> already working fine...

These are real pain points, yes, because higher-level features, for 
which there are no replacements, have been remove from the core domain 
of Qt: UIs.

I fully agree with you on that one.

> From a utopic point of view, Id be fine with, if every Qt container,
> and class that has been "mostly" implemented in STL, or the native
> language was thrown out.. But as I tell my employees, just because its
> in the language now, doesn’t mean we should go through our 2.5 million
> lines of code, and re-write every one to use modern C++...

I disagree here with you here, though. You have had nine years now for 
realising that QList is a bad container to use in your code

 From 
https://marcmutz.wordpress.com/2010/07/29/sneak-preview-qlist-considered-harmful/ 
(2010):

> Run, don’t walk, and fix your new API to not use QList,
> or mark your new types as movable (details are in the
> patch). Alas, both changes are binary incompatible, so
> you can’t do them if you need your code to stay BC.
> This might be one of the reasons why QPair and QVector
> aren’t “fixed” yet: doing so would change the layout
> of the QList instantiated with them :(.
> 
> But, at least for new code, there’s no excuse anymore:
> Just apply the patch.

You've had anywhere between eight years to manually and now to 
automatically run clang-tidy on your code to port at least those 
variables that name QList to auto, isolating you from the fallout that a 
QList removal would have. If you still use QList in your code today, 
then, I'm sorry, it's your own fault. You follow the development list, 
so the same is true for Q_FOREACH, for you.

You can also use the Qt containers, but restrict yourself to the 
STL-compatible subset of the API. And then the transition is as easy as 
s/QVector/std::vector/. That has been possible since Qt 3.0.

So, this case differs greatly from the two instances of feature removal 
you mentioned above in that you had literally years of time to prepare a 
coding style that would all but isolate you from the exact type of 
container used. The STL containers exist in standard form since 1998, 
and since then you had time to port your own code away from Qt 
containers, further isolating you from one of the most 
code-churn-producing subsystems of Qt: containers. If you've been with 
Qt since Qt 3 or Qt 2, you know what I mean. And if you have not learned 
from Qt 2 -> Qt 3 or Qt 3 -> Qt 4 w.r.t. to containers, then - sorry - 
again: your own fault. Had you ported to STL, your code would stay 
unchanged.

I'm playing devil's advocate here. In reality, yes, I want the rebase of 
Qt onto modern C++, for a great many reasons, but I'm also always 
looking for a way how to do that without disruptive changes. But that 
requires that Qt users compile with deprecated warnings enabled and fix 
their code small steps at a time. There are not many libraries that keep 
SC for so long as Qt does. But very long is not forever, and change will 
come one way or another. The good news is that C++11 allows you to 
insulate your code in many ways (auto, unordered_*), and this is 
precisely why we can now take this step.

> To replace out every container, that works today?  And in the process,
> break probably billions of lines of existing Qt code, which would have
> to be re-written using the new containers???  Please don’t....  Even
> for 6.0...  Some form of transition would be great.

Upon reading the recent mails in this thread, one could have noticed 
that this whole subthread started with an unrelated topic: _not_ making 
QList an alias to QVector. I'd prefer the discussion to pick up on that 
technical point, even though I appreciate that it's easier to just 
generally vent FUD in a bike-shedding frenzy than to seriously consider 
technical issues such as how we can remove QList with minimal 
disruption.

@all:
I will no longer reply to the Views subthread, because it has gone 
off-track, as usual. Please give your valued input on a way forward 
regarding QList removal (QList subthread).

Have a nice weekend,
Marc