[Development] Lack of base classes/interfaces? Q*, Q*F

[Alejandro Exojo]

On Monday 17 April 2017 03:25:49 Jason H wrote:
> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point,
> etc]) don't use an interface? I recently moved some code from ints to
> floats, and I had to change far more code than I should have had to.
> 
> My proposal is to change QRect to QRectI, and make QRect an interface.

Have you thought this through? What would that interface or base class return 
for x()/y()/width(), etc?

Classes like this are normally named "value classes" because you should 
consider them like like regular values that the language provides. That is, 
like int or float, for example, which is very appropriate for the case that 
you bring. Do you really think that there should be a base class for int and 
float? Some languages have that, but follow very different design principles.

You should really explain which kind of code did you change, because just 
recently I adjusted code from using a key press event to a touch event, and 
the point had to change from QPoint to QPointF, and the changes were minimal. 
This wasn't explained to me, but I just found it natural. Also:

https://wiki.qt.io/API_Design_Principles#Static_Polymorphism
 
> In the past, I think I remember some pain points between QList and QVector,
> (or was it QMap, QHash?) which should be QIterable (QIndexable)? Similarly
> all the string types. 

Again I don't see which your problem was. All the containers have a very 
similar API, and the string types too. The algorithms in the standard library 
go to the extent that work with any container (including Qt containers) that 
provides some features and don't need a base class.

And you don't need to be a low-level C++ developer that crafts algorithms and 
writes containers to end up writing code like this, or to see it valuable. 
Some time ago I did a simple proof of concept that used the same code to draw 
with QPainter on a QWidget, QQuickPaintedItem and QRasterWindow. I did it when 
I found the existence of QRasterWindow, saw the similarity of API, and though 
"this could be interesting".

So sorry, you will have to explain more details of what your problem was, 
because it's not clear at all (at least to me) what is so problematic. You can 
use the same kind of container in a foreach or range for loop. You can use the 
same kind of iterator. QList has a lot of convenience API that QVector gained 
as well for easing the porting. So what's left?

-- 
Viking Software, Qt and C++ developers for hire
http://www.vikingsoft.eu