[Development] QList

[Lars Knoll]

On 24 Mar 2017, at 17:18, Marc Mutz <marc.mutz at kdab.com<mailto:marc.mutz at kdab.com>> wrote:

On Friday 24 March 2017 16:34:17 Thiago Macieira wrote:
Em sexta-feira, 24 de março de 2017, às 01:34:18 PDT, Marc Mutz escreveu:
I listed _the_ three use-cases where inheritance is the tool of choice:

1. modelling is-a
2. inheriting to reuse
3. reimplementing virtual functions

If your use-case is not one of the three, then inheritance is not the
right tool.

Clearly, by now, it's neither (1) nor (3). So if anything, it needs to be
(2).

And I'm arguing that it's not (2), either, because you can only re-use a
subset of QStringView API, and need to wrap the other half anyway. (2) is
really only interesting for pure OO languages with no concept of free
functions. In C++, we have free functions.

Marc, philosophical question then:

Are you of the opinion that private inheritance has no purpose and should
never be used?

No, and if you look at code I have written over the years, you will see that I
do use it.

One thing I've looked into in the past is this: Q6Polygon should inherit a
Q6VectorBase<QPoint> that also Q6Vector<QPoint> inherits. This will allow easy
specialisation of QVector<T*> by inheriting QBasicVector<const void*>.

I can even think of a similar pattern for QStringView/QLatin1(String|
View)/QUtf8(String|View), though I guess that just enable_if'ing functions out
of the primate template will do the job just fine, so the three classes would
be mere typedefs of the template.

But in these cases, we're reusing next to 100% of the functionality, by way of
lots of using Base::foo; This is not the case for QString : QStringView.
They're completely unrelated, because one if owning and the other is non-
owning.

I am with Marc here. I don’t really see any advantage of inheriting QString from QStringView. Rather I think it’ll confuse people, even if the inheritance is private.

The pattern I currently think would be best is the following:

Make QString and QStringView two independent classes. Share most of the implementation, by either making the const methods in QString call the methods in QStringView (as in QString::indexOf(…) { return QStringView(*this).indexOf(…); }) or by having both call independent methods. The second option might lead to slightly more efficient code, but for operations such as indexOf() I do not think this would matter in practice. On the other hand, the second option might lead to more confusing stack traces if people are debugging their code. In any case, if we decide to go for the second option, I would however like us to move most of these freestanding methods into a (hidden) namespace.

Another point that hasn’t been discussed yet, is how to handle QStringRef. In my opinion, we should deprecate it, but it’s used quite a bit in some parts of our API (QXmlStreamReader comes to my mind). It would be good to also think about how to solve that case. QStringRef has a pointer to a QString, but does not increase the refcount of it. So it looks like we can simply make it an alias for QStringView. That would break the QStringRef::string() method (which we should probably deprecate in 5.10 to prepare for the change), but everything else should stay compatible.

Cheers,
Lars

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170327/52690e36/attachment.html>