On Thursday 11 June 2015 23:15:20 André Pönitz wrote: > That's exactly the kind of situation I was referring to in my previous > mail: This is intentionally introducing API inconsistency. It does not > really matter to me whether "poor-man's prefix name spacing" is > unfashionable or "we" consider it bad. It is simply inconsistent with > more than 200 of existing exported QQuick*, QSG* and QQml* classes.
For me, QQuick*, QSG*, QQml* are as much inconsistent with QtCore, QtGui and QtWidget (excepting QGraphics*) naming, where none of the types starts with poor man's prefix namespacing, as Qt3D::QParameter and QQml*. Indeed, if you're working an a classical QtWidgets application, you might be very surprised about all those common prefixes in other modules, and annoyed by having useless code completion on class names beginning with QGraphics... :) And as Qt grows and grows, the chance of name clashes increases (http://en.wikipedia.org/wiki/Birthday_problem), as witnessed by the introduction of namespaces for disambiguating names from QtQuick1 and QtDeclarative. QtMultimedia (which largely uses traditional names) has several common names, too. Namespaces, if the whole module is wrapped, and the namespace name is derived consistently from the module's soname, provide a reliable partition of the name space. If a new library cannot change the established ways, including to experiment with it, then Qt will be forever locked in its 90s API, because, let's face it, come Qt 6, no-one will have the time to implement nor the incentive to break SC in such a broad way as to lift all of Qt to a new API standard, on top of all the work that will go into C++11/14-enabling the API, and the inevitable work on the containers. And the pain will grow and grow. So, giving each module the leeway to modernize its API at its own pace seems to me the only workable solution. Of course, APIs should still be consistent, but whether a module uses namespaces or not doesn't really influence the consistency. Setters for text will still be called setText() and getters text(), QObject subclass' ctors will still end in QObject *parent = 0^Wnullptr, etc. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
