D10378: Deprecate KFileItemList and introduce KFileItemListV2

[David Faure]

dfaure added a comment.


  I would deprecate KFileItemList only when KFileItemVector is a valid replacement (i.e. all the APIs in KIO use KFileItemVector). Deprecating while people are still forced to use it, only leads to a habit of ignoring deprecation signals (since there's no other solution). Introduce Vector, but don't deprecate List just yet.

INLINE COMMENTS

> kfileitem.h:550
> + * @deprecated To allow further optimisation opportunities, move semantics are desired.
> + * QList does not support those. Also, QList is generally seen as a bad container.
> + * Therefore deprecating this in favor of @see KFileItemListV2 is resolving both issues.

It's not bad, when sizeof(T) == sizeof(void*), which is the case here.

The point about move semantics remains, but that's the only one; let's stick to facts in comments.

> kfileitem.h:553
> + * KFileItemListV2 is only a partial replacement though. The convenience member
> + * functions of KFileItemList are gone in it's successor.
>   */

it's -> its

But why not add those convenience methods again, one way or another? Otherwise we'll have massive code duplication.

> kfileitem.h:591
> + *
> + * List of KFileItems in a std::vecor container.
> + * @since 5.44

typo: vector

> kfileitem.h:594
> + */
> +using KFileItemListV2 = std::vector<KFileItem>;
> +

How about naming KFileItemVector instead? Much cleaner name.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10378

To: markg, dfaure
Cc: #frameworks, michaelh, ngraham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180208/1738ddfd/attachment.html>