[Development] Proposal: Deprecate QVector in Qt 6
Elvis Stansvik
elvstone at gmail.com
Thu Apr 23 12:48:45 CEST 2020
Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs <laszlo.agocs at qt.io>:
>
> That depends on the number of the functions affected, and how commonly those are used. If we are talking about just a few virtual functions here and there which are not expected to be overriden by a vast majority of applications (such as the QIconEngine example), then changing the signatures is probably acceptable. After all, Qt 6 will have a number of source compatibility breaks (typically in less commonly used APIs) anyways, let's have no illusions here. So on its own this should not be an argument for reprioritizing the tainted QList name.
>
> For years we have been teaching people to stay away from QList and treat it as a legacy thing in the API, and that it may change in a future major release. Any newly introduced public APIs (in the graphics-related areas at least) for the past 5-6 years are using QVector. It is odd to turn this over just like that.
I have to agree with Laszlo here. The message has been that QList due
to its duality etc is problematic and may become deprecated, so we've
put in work on changing it to QVector in our code bases, and used
QVector in newly written code. It's a bit annoying if QList is now to
become the name to be used. I'll accept whatever is decided, but think
it's a little unfortunate if we'd have to change all that code back to
QList again.
Elvis
>
> Best regards,
> Laszlo
>
>
>
> ________________________________
> From: Simon Hausmann <Simon.Hausmann at qt.io>
> Sent: Thursday, April 23, 2020 10:52 AM
> To: Laszlo Agocs <laszlo.agocs at qt.io>; Jaroslaw Kobus <Jaroslaw.Kobus at qt.io>; Lars Knoll <lars.knoll at qt.io>
> Cc: Qt development mailing list <development at qt-project.org>
> Subject: 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.agocs at qt.io>
> Sent: Thursday, April 23, 2020 10:41
> To: Jaroslaw Kobus <Jaroslaw.Kobus at qt.io>; Lars Knoll <lars.knoll at qt.io>; Simon Hausmann <Simon.Hausmann at qt.io>
> Cc: Qt development mailing list <development at 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-bounces at qt-project.org> on behalf of Jaroslaw Kobus <Jaroslaw.Kobus at qt.io>
> Sent: Thursday, April 23, 2020 10:20 AM
> To: Lars Knoll <lars.knoll at qt.io>; Simon Hausmann <Simon.Hausmann at qt.io>
> Cc: Qt development mailing list <development at 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-bounces at qt-project.org> on behalf of Lars Knoll <lars.knoll at 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.Hausmann at qt.io<mailto:Simon.Hausmann at 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 at qt-project.org<mailto:Development at qt-project.org>
> https://lists.qt-project.org/listinfo/development
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
More information about the Development
mailing list