[Development] QList

[Marc Mutz]

On 2017-03-23 19:27, Thiago Macieira wrote:
> On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote:
>> NAK to inheriting from QStringView, publicly or privately. NAK to 
>> adding
>> another pointer.
> 
> BTW, just to be clear: I am not accepting this discussion as closed. I 
> only
> had this idea a while ago, so I have not yet throught it completely 
> through,
> so I reserve the right to discuss it later.
> 
> In the mean time: why do you care if some class derives from 
> QStringView?

Because it's _wrong_.

It does not model is-a, so public inheritance is out of the question.

QString cannot use a lot of QStringView functions (like mid()) without 
changing at least the return type, so inherit-to-reuse-implementation is 
also not valid.

Last, there are no virtual functions in QStringView that QString would 
want to reimplement.

So, of the three use-cases for inheritance, none are relevant here, so 
it follows that inheritance is not the tool to use. You may consider 
composition, though, as I said, I'd rather provide free functions that 
most QString/View methods forward to than picking one class and calling 
its methods from all others.

> We certainly need to discuss the presence of an extra pointer inside, 
> as that
> has a cost. But derivation?

Derivation is the strongest coupling mechanism in C++, after friendship. 
Do I need to mention QPolygon and what pain it's inheritance from 
QVector<QPoint> has caused? (FTR: cf. end of qvector.h and 
qvector_msvc.cpp).

Thanks,
Marc