Hi, You're right, I was mistaken. I tried the virtual method API change locally and it works with the aliasing, either way. So it's only a problem if we combined it with deprecation and asked our users to move over while they want to maintain compatibility with both versions of Qt. Thiago's proposal on the other hand avoids the deprecation.
Simon ________________________________ From: Development <development-boun...@qt-project.org> on behalf of Fabian Kosmale <fabian.kosm...@qt.io> Sent: Thursday, April 23, 2020 11:08 To: development@qt-project.org <development@qt-project.org> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 Hi, I don't see the issue with the search&replace with virtual functions. In Qt 5, those use QList, so our users will use it there too. In Qt 6, we change it to QVector, but as QList is an alias of QVector in Qt 6, the user's code (still using QList) will still work just fine. Am I missing something here? Fabian -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ________________________________ Von: Development <development-boun...@qt-project.org> im Auftrag von Simon Hausmann <simon.hausm...@qt.io> Gesendet: Donnerstag, 23. April 2020 10:52 An: Laszlo Agocs <laszlo.ag...@qt.io>; Jaroslaw Kobus <jaroslaw.ko...@qt.io>; Lars Knoll <lars.kn...@qt.io> Cc: Qt development mailing list <development@qt-project.org> Betreff: Re: [Development] Proposal: Deprecate QVector in Qt 6 Hi, If we did the search & replace and use QVector throughout our API, won't that make it harder for our users to maintain a code base with 5 and 6? For example if we change the signature of virtual functions. I think we'd do our users a favour by sticking to QList - I'm not concerned about the popularity of Qt in online forums but rather about the practical difficulties of developing with Qt. Simon ________________________________ From: Laszlo Agocs <laszlo.ag...@qt.io> Sent: Thursday, April 23, 2020 10:41 To: Jaroslaw Kobus <jaroslaw.ko...@qt.io>; Lars Knoll <lars.kn...@qt.io>; Simon Hausmann <simon.hausm...@qt.io> Cc: Qt development mailing list <development@qt-project.org> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 -1 for QList. Why reuse and prioritize a name that has been tainted by plenty of past discussions and comes with a lot of past baggage? Any Google etc. search will bring up plenty of "QList-bad QVector-good" materials for years to come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is not going to disappear overnight. The current status quo of QList being an alias to QVector in Qt 6, with QVector being the primary and recommended name, is pretty good IMHO, it is not clear to me why this would need any further changes. An additional search & replace (QList->QVector) round in the public headers does not sound like a bad idea at all. Best regards, Laszlo ________________________________ From: Development <development-boun...@qt-project.org> on behalf of Jaroslaw Kobus <jaroslaw.ko...@qt.io> Sent: Thursday, April 23, 2020 10:20 AM To: Lars Knoll <lars.kn...@qt.io>; Simon Hausmann <simon.hausm...@qt.io> Cc: Qt development mailing list <development@qt-project.org> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 +1 for QList. (6) No need to remane QStringList into QStringVector for consistency reasons. Jarek ________________________________________ From: Development <development-boun...@qt-project.org> on behalf of Lars Knoll <lars.kn...@qt.io> Sent: Thursday, April 23, 2020 9:53 AM To: Simon Hausmann Cc: Qt development mailing list Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 I’ve had similar thoughts lately as well. I can see a few more reasons to keep QList as the name of the class: (3) Less ambiguity with QVector(2/3/4)D (4) QList is the known type and the one promoted in our API so far, so no need for people to re-learn Qt (5) a lot less code churn for us and our users So I’m in favour of doing this and keeping QList as the name for the class. Cheers, Lars On 23 Apr 2020, at 09:43, Simon Hausmann <simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> wrote: Hi, In dev we've had QVector being an alias for QList for a while now. For the 6.0 release this particular topic (QList/QVector) suggests two goals (among others): (1) Use the same type throughout the public API of Qt. (2) Make it easy for our users to maintain a code base that works with Qt 5 and 6. In the light of those two goals, I think we should keep using QList as the type in the public API. I don't think we should do a search and replace activity and switch to QVector. In the light of that, I would like to propose simply deprecating QVector and stick to QList everywhere. What do you think? Simon _______________________________________________ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
