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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
