[Development] final value classes: some background information and plans

[Marc Mutz]

Hi Lars,

On Wednesday March 7 2012, lars.knoll at 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? 

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions