[Development] Deprecation/removal model going into Qt 6

[Giuseppe D'Angelo]

Il 03/06/19 23:04, Kevin Kofler ha scritto:
> Giuseppe D'Angelo via Development wrote:
>> Also, please name me 3 GUI frameworks that have not broken APIs for 30
>> years.
>>
>> Also also, please name me 3 libraries that have not broken APIs for the
>> 30 years.
> 
> There is at least one (almost): Win32 has now existed for 26 years without
> an ABI break.
> 
> That said, it is painful to use (directly), proprietary, and not portable.
> But we have to admit that they did really well at maintaining compatibility.

Some API has been dropped by Win32 (first that comes in mind is NDDE). 
Still waiting for the other examples. (Anyhow, last time I checked, the 
development power behind Qt is a tiny fraction of the one available to 
Microsoft. I brought up the development bandwidth problem already.)


>> Also also also, at least in the x86-64 world, major "API breaks" at the
>> assembly level have already somehow occurred. And that's an architecture
>> that has been around for less than 20 years.
> 
> Have they really? Software built for the first x86_64 CPUs still runs
> unchanged, doesn't it?

If you want your software to have security issues, yes. Otherwise you'll 
need to change your assembly. That's an API break in my book.


>>> Qt has also become larger and larger over time (despite the removal of
>>> APIs considered obsolete).
>>
>> The removal of APIs in Qt 5 lifetime has been mostly "limited" to
>> dropping entire obsolete modules. No cleanup has been done to deprecated
>> API inside a module.
> 
> I was comparing the size of Qt 3 and Qt 5. There have been 2 such cleanups
> between them: Qt 4.0 and Qt 5.0. Still, Qt 4 was much larger than Qt 3, and
> Qt 5 is much larger than Qt 4 was.
> 
>> Qt 6 wants to do that, and the point of this thread is how to minimize the
>> pain.
> 
> And my point is that the only way to minimize the pain is to just not do
> that to begin with.
> 
> There needs to be a point where a library just stops doing new incompatible
> major releases. See how glibc has now been at glibc 2 (libc.so.6) for 22
> years.


... Glibc has done countless API breaks:

> https://raw.githubusercontent.com/bminor/glibc/master/NEWS




>> The intended _scriptable_ solution is
>>
>> 1) copy and paste Q_FOREACH from qglobal.h into a central header of your
>> project
>> 2) rename all occurrences it to MY_FOREACH
>> 3) done
> 
> That (telling the users to just copy&paste the code from the library)
> defeats the whole point of a software library.

Because Q_FOREACH does not belong to Qt. How about this: put it in a 
separate library, publish it to github, and port projects to use _that_ 
instead? It's still 100% scriptable.



>> This is just *false*. You're (deliberately?) ignoring the cost of memory
>> allocations and deallocations, hiding them in big-O constants, something
>> I already warned you about. I won't then waste time debunking this.
> 
> If you have a list of 1000000 800-byte objects and you want to insert an
> element in the middle of the list, with a reasonable malloc implementation,
> the ONE allocation together with the 4 MB memmove for QList::insert will be
> negligible compared to the 400 MB (!) memmove for QVector::insert.

Third straw man in three emails. Inserting in the middle of a sequential 
container with a million elements is NOT a common use case. While at it, 
why don't you also measure the cost of iterating over the elements, as 
already suggested in an earlier email?


>>> Of course, that doesn't imply that it is not possible to do better, in
>>> theory. But is this optimization [SSO] worth the trouble of breaking the
>>> ABI?
>>
>> Yes.
> 
> And that's what I doubt, and you have not stated any arguments for your
> claim.

So you want me to dump here all the existing literature available around 
the benefits of SSO, for the sake of... what exactly? SSO is not an API 
break and therefore discussion about it does NOT belong to this thread.


Quite bored now,
-- 
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: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190604/d3f254af/attachment.bin>