[Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Volker Hilsheimer]

> On 20 Mar 2021, at 14:22, Roland Hughes <roland at logikalsolutions.com> wrote:
> 
> I grepped the archive this morning. Hopefully Andre's email still works. I had hoped he was still watching on here and would pipe up. Maybe he and his company abandoned Qt as well after the June 2020 exchange?
> 
> Here is a scrape of one of the messages in the thread from the archive.
> 
> Subject: [Interest] Set manipulation in Qt 6
> In-Reply-To: <2dbe5c20-648d-02bd-745d-4415449f1a6e at kdab.com>
> References: <CAK-8PPRmYe1KKjDf=zd0Rv=X-dj=6tk4Mayz3xREnTe1sKjEug at mail.gmail.com>
>  <2dbe5c20-648d-02bd-745d-4415449f1a6e at kdab.com>
> Message-ID: <20200621172617.GB11000 at klara>
> 
> On Sat, Jun 20, 2020 at 12:34:11PM +0200, Giuseppe D'Angelo via Interest wrote:
> > With my hat of the guy going around and deprecating toSet() and friends: the
> > rationale for these deprecations is the terrible code that those methods
> > encourage, and the
> 
> While I sympathize to some degree with the performance motivation behind this
> kind of removal of convenience functionality this has to be put into perspective
> of the price you charge:
> 
> We had to spent a significant amount of our time during the last year to
> keep up with the deprecations within the last releases in the 5.x series.
> This includes re-inventing parts of the abandoned qalgorithm as part of
> our code base.
> 
> The toSet/toList changes alone involved touching 200+ locations in the code
> base and I am not aware of even a single noticable performance improvement
> as a result.
> 
> A back-of-the-envelope calculation with generous assumptions on user count and
> usage frequency makes me believe that the accumulated win on saved computer
> time does not even offset the amount of manual work that had to be spent
> on these changes.
> 
> On top of that goes the more complex and consequently harder to read re-written
> code, plus the chance of introduction of actual regressions in the code.
> 
> The latter is btw not just theoretical, I noticed only last Friday the hard
> way that blindly replacing QLinkedList by std::list can transform previously
> correct and working code into a crash. Having to thoroughly check each and
> every such replacement only to get in the best case the same functionality
> as before is an awful value proposition.
> 
> To summarize: If you despise wasting cycles for convenience that's fine.
> Assuming that everyone else shares this preference is already odd. Making
> other people pay for this is simply wrong.
> 
> > (Which brings me to my second crusade, try stop encouraging the usage of Qt
> > containers, as their API is full of holes and doesn't play nice with
> > algorithms or ranges. But it's enough for this mail.)
> 
> If you want to use Qt without Qt that's fine. But please stop making other
> people suffer from your choices.
> 
> Andre'


Andre being one of the Qt Creator developers is of course in a very special place. Not only because the Qt Creator team has decided that they want a single code base that builds against both Qt 5 and Qt 6. Doing so as Qt 6 was being developed of course resulted in more churn - but also in good feedback. Either way, it is perhaps not the most representative porting experience.

Roland, if you have specific 1st hand porting experience to share and constructive contributions to make about which APIs we should bring back because, then please do so.

Cheers,
Volker