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

[Giuseppe D'Angelo]

On 24/03/2021 13:49, Matthew Woehlke wrote:
> Let's take e.g. QList::toSet as an example. The deprecation message says
> to use `QSet(list.begin(), list.end())` instead. How, then, is the
> correct implementation*not*:
> 
>     QSet<T> QList<T>::toSet() { return QSet<T>{begin(), end()}; }

That is the correct implementation, but the deprecation functions aren't 
about "how this ought to be implemented into Qt".

> 
> What was so hard about that? If that's wrong, then so AFAICT is the
> deprecation message.

Probably. There's only so much space for the message in them. I'm trying 
to point out that the specific motivation here isn't even remotely 
_technical_ (e.g. is this hard to implement correctly; as you've shown, 
it's super easy), but a _design_ one (is this API *good*?).

And anyways these methods are still fully supported within Qt 5.


> 
> Yes, it does not generalize to every possible container type, but I
> don't know that anyone is asking for that (and I agree we shouldn't try
> to support that). 

All the contrary, this is one big crux of the problem: toX() for a 
completely arbitrary closed set of X is bad API. Why QSet::toList and 
not toVector? Why QList::toSet and not, say, MULTI sets? If you want 
stability of references and can't use Q6Set but want std::unordered_set, 
why there isn't a function for that? And so on.

This is calling for a more generic toX() API. Which isn't easy to 
provide within the quality constraints of QtCore. If it were, don't you 
think Yours Truly would already have provided it? Do I sound *that* evil 
that I enjoy crippling for the sake of it? :-(



We're not talking about adding many, many variations
> upon this theme, just*not*  removing the ones that already existed. The
> ones that do exist, exist because they are more convenient to use, and
> because they cover*the most common*  use cases.

Can I hear some use cases then please? Because from the experience of 
usages within Qt, it was a nail/hammer problem, call it an education 
problem ("I know containers; I don't know algorithms; let me use 
containers to solve an algorithmic problem"), of which we're entirely 
responsible (Qt docs teach a lot about containers, but not about 
algorithmic design.)


Miscellanea examples from Qt itself,

* I need to remove duplicates from my list, let me do:

> list = list.toSet().toList();

* I need to keep the list, process it in order, but avoid processing 
duplicate elements; 99% of the time the list is a handful of elements; 
let me do

> QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem); process(elem); } }
* I've got a square peg (a QList) and a round hole (an function I made 
that takes a QSet), so I need conversions to call it.


And so on.

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210324/35cbbc8e/attachment.bin>