[Development] Some Qt3D feedback

[André Pönitz]

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.

Andre'