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

[Roland Hughes]

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'

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog