[Development] Some Qt3D feedback

[Simon Hausmann]

On Friday, June 12, 2015 10:52:35 PM André Pönitz wrote:
> On Fri, Jun 12, 2015 at 12:58:42AM +0200, Marc Mutz wrote:
> > 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*.
> 
> Generally useful stuff goes to QtCore, less general stuff is found in "leaf"
> modules. Commonly used items get short names, leaf items longer ones. It's
> a kind of Huffman code at heart. Using poor man's prefix namespacing is one
> way out. Not the only one, not necessarily the best, but one seen in real
> life and one that's known to work.
> 
> > And as Qt grows and grows, the chance of name clashes increases
> > (http://en.wikipedia.org/wiki/Birthday_problem),
> 
> I had cherished some hope that Qt class names in leaf modules are not chosen
> according a discrete (almost) uniform distribution. Looks like I stand
> corrected. [1/2 ;-)]
> 
> The good news is that even the most stupid version of prefix namespacing
> (QModuleXXX) solves this nicely, as it restricts the potential of conflicts
> to the module itself.
> 
> > 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.
> 
> It is easy to predict that the use of proper C++ namespaces immediately
> opens the door to bikeshedding on the merits of using declatations and
> using directives. It is as easy to predict that the Modernizers will claim
> that the only true solution is to use fully qualified names, everywhere. We
> will end up with a random mess of old style identifiers and newfangled
> ones, with additional :: line noise on top of what we'd get by poor man's
> namespacing, without the bikeshedding effort.
> > 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.
> There's quite some room for experiments in playground projects. I don't
> consider "Qt proper" as the appropriate venue for experiments. I would
> likely see that less strict if there were less strict compatibility
> requirements allowing to correct failed experiments. But as it stands, we
> have them.
> 
> I tend to agree that the transition from Qt 5 to 6 will ask for a painless
> upgrade path again. We had rather good experiences with the large degree of
> source compatibility from 4 to 5. Less so from 3 to 4. The main point here
> is that an upgrade path does not necessarily require full source
> compatibility, it "only" needs to either allow for code being compilable
> with both version, possibly after some massaging of the original code base,
> *or* a mostly automated migration. Since going from QFooBar to QtFoo::QBar
> is possible in both cases, using poor man's namespacing in Qt 5 does not
> add significant technical debt.
> 
> > 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.
> 
> It does by itself as the namespace is part of the API. And it adds more
> opportunities for even less consistency, see the reference to the use
> of 'using' above.

I agree with André.

The use of namespaces in the implementation of Qt modules is common by now, 
the use of namespaces visible to the users of Qt through our public API is 
_not_ common and it is inconsistent with the rest of Qt at this point - as 
unfortunate as this is. In my opinion we should revisit this only by the time 
we're discussing a big API break.


Simon