[Development] Views

[Konstantin Shegunov]

On Mon, May 20, 2019 at 11:32 PM Mutz, Marc via Development <
development at qt-project.org> wrote:

> All I'm saying is that there are tons of examples (QGradient) where the
> use of an owning container in the API is just a very bad idea and limits
> the implementor's freedom and/or performance. E.g. QGradient could have
> inline storage for two or three stops to avoid allocating memory for the
> most-common cases. I mean, QPainter is full of (QPoint *, int nPoints)
> APIs that surely were added just for performance. Ditto for QString,
> btw. Nowadays, with views, we can have the same API, but have it accept
> many owning containers transparently. I'm not saying that there must be
> no owning containers in the API. But there is a lot of low-hanging fruit
> out there.
>

Okay, I can live with that, and I do see why it'd make sense in some cases
to iterate the data directly. But then as a container can have many
different iterables, it seems reasonable to consider adding a couple of
methods that return views and take it from there. Why the push to remove
the owning container(s) API? In time it may prove you're right, so then we
can migrate the getters to the view API and eventually deprecate these
methods. Or they could coexist, or w/e. The point is why reach for the top
if there's low-hanging fruit?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190521/9da27e25/attachment.html>