On 3/7/12 8:18 PM, "ext Marc Mutz" <marc.m...@kdab.com> wrote:
>Hi Lars,
>
>On Wednesday March 7 2012, lars.kn...@nokia.com wrote:
>> I very much agree with Andre and Jedrzej. I don't see little value added
>> here, and I actually even see quite a few useful cases for public
>> inheritance, like QPolygon.
>
>Thanks for bringing up QPolygon, because I don't think good API works
>like
>this:
>
>QPolygon polygon(4);
>polygon[0] = QPoint(0,0);
>polygon[1] = QPoint(10, 0);
>polygon[2] = QPoint(10, 10);
>polygon[3] = QPoint(0, 10);
>painter.drawLines(polygon); // doesn't do what it says!
>
>Sure, in this case it's easy to spot by looking at the result, but
>imagine
>this was a data plotter with thousands of points, maybe even using a pen
>style != Qt::SolidLine...
>
>(I guess I should submit a patch that marks
>QPainter::drawLines(QPolygon{,F})
>as deleted...)
>
>> So no, I'm against making value classes final.
>
>This strikes me as an overly broad statement. People have been vocal
>about
>containers and QString not being final, shared pointers, too, and I can
>see
>how that would be a nuisance for legacy code out there, and unwanted at
>this
>point in the Qt5 release, but what about - say - QMutexLocker?
There are certainly classes where this would most likely not break a whole
lot of code. But how much do we really gain from it?
Disallowing the inheritance might help avoid some slicing bugs, but it
also makes other things harder. If you only use the derived class class
on the stack actually all inheritance is safe. It's only if you use them
on the heap in a polymorphic way that you get issues.
Yes, one could debate QMutexLocker, but I want us to start thinking about
getting a release out not doing more and more API changes that add
relatively little value.
Cheers,
Lars
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
