[Development] Some Qt3D feedback

Marc Mutz marc.mutz at kdab.com
Thu Jun 18 12:45:53 CEST 2015


On Thursday 18 June 2015 09:08:18 Simon Hausmann wrote:
> On Wednesday, June 17, 2015 03:36:11 PM Marc Mutz wrote:
> > On Wednesday 17 June 2015 12:56:54 Knoll Lars wrote:
> > [...]
> > 
> > > * connect statements are hard with namespaces. Old style connects could
> > > easily break if you forgot to fully qualify a parameter. New style
> > > connects might end up with rather ugly looking syntax.
> > 
> > This is nothing new. We have that for nested classes and enums already,
> > as well as typedefs.
> 
> Right, but that's a _very_ different scale, isn't it?

No. How many people, do you think, use 
QAbstractSocket::error(QAbstractSocket::SocketError), compared to, say, Qt3D? 
I'd say: more.

> > If you ban namespaces based on this, you need to ban
> > nested types (e.g. error enums), too.
> 
> Marc, the goal if this discussion is not to impose a ban of any sorts. I'm
> not sure where that term suddenly comes from. Ultimately our goal should
> be to find a solution to introduce namespaces in the public API of Qt in a
> manner that is consistent, preserves the ease of use of Qt and preserves
> source compatibility.

It was already determined, when going from Qt 4 to 5, that you cannot make the 
switch to namespaces in a souce-compatible manner. Insisting on source-
compatibility, having ruled out the new ideas Lars included in his mail, thus 
constitues a ban of namespaces until source incompatibilites are acceptable 
again (if they ever will be).

> > > * metatype registration is problematic with namespaced types, as the
> > > macro extracts the name of the type through the preprocessor. People
> > > can very easily end up registering the type multiple times with
> > > different (qualified vs non qualified) names.
> > 
> > Same counter-arguments as above, but Q_DECLARE_METATYPE with namespaces
> > is actually easily fixed by internally prepending ::, thus making sure
> > the argument is a fully-qualified name.
> 
> I'm not sure I understand that point. If we have
> 
> namespace QtFoo {
>     struct MyType {
>         ...
>     }
>     Q_DECLARE_METATYPE(MyType)
> }
> 
> then how can we register MyType fully qualified in the type system?
> 
> Or would the idea be to place the Q_DECLARE_METATYPE outside of the
> namespace?

As others have already pointed out, Q_DECLARE_METATYPE needs to be outside any 
namespace. The reason is that it internally QT_BEGIN_NAMESPACEs.

> > > * One of our coding guidelines is that you write code once, but read it
> > > many times. Code written should be as self explaining as possible.
> > > Having generic class names inside an implicit namespace makes this
> > > difficult, as information is not fully local anymore (you have to know
> > > that there’s a using directive at the beginning of the file to find
> > > the proper qualified class name). Generic and duplicated names from
> > > different namespaces can easily lead to confusion when reading code.
> > > (btw, this is also an argument against over-using auto)
> > 
> > Purely subjective, and highly controversial in the wider C++ community
> > (with the controversity mainly between Qt and the rest of C++, afaict).
> 
> Whether or not that is controversial in the wider C++ community is by
> itself controversial ;-). At this point I would argue that we lack data
> from people who are enjoying the Qt API as it is today and people who do
> not like it. Unfortunately I don't think that we can sensibly collect the
> data, so I think it remains a controversy.

As a decade-long consumer of Qt API, and only recent contributor, I can tell 
you that what matters is not the name or classes (as long as they start with a 
Q), but the names and semantics of functions, and the order of constructor 
arguments. If class name consistency was an issue, then QTextEdit would have 
been called QMultiLineEdit or QLineEdit would have been called QTextLineEdit.

As a decade-long consumer and producer of KDE API, I can tell you that I never 
found the use of namespaces in public KDE api irritating or whatever.

> > > * class name prefixing is a widely used and understood scheme by our
> > > users. Do we really want an inconsistency now in one place? I don’t
> > > think we have enough arguments to actually go down that route.
> > 
> > Show me one C++ library not of Qt origin that uses class name prefixes
> > not due to backwards compatibility concerns.
> 
> Can you elaborate how the question relates to the argument?

It relates to the claim in the quoted text that name prefixing is widely used 
and understood by users. IMO, namespaces are even more widely used, as well as 
sufficiently well understood inside C++ and outside Qt. Proof: std:. and 
boost:: are used in more projects than is Qt. In fact, I don't know any C++ 
library that uses namespace prefixing that hasn't gotten this from Qt (KDE).

> I think there are two decisions on the table:
> 
> 1) What do we do in the short term with Qt3D in relation to the rest of Qt?
> 
> 2) What are the things that we need to do to properly support namespaces in
> the API throughout the entire framework. (hence the point about run-time
> aspects of the meta-type system and the moc)

I don't see a consensus for moving to namespaces. I see suggestions for 
experiments, with claims that stuff should stay SC. I see claims that either 
the :: is superfluous or else the using directives obfuscate the code.

The meta-type system and moc are perfectly fine with namespaces. If people 
would just peek over their own noses and over to your cousin, KDE, you'd see 
that, say, kdepimlibs would have a very hard time indeed, if QMetaType or moc 
would have any trouble with namespaces whatsoever.

> Some people (including myself) are concerned that one module with extensive
> use of namespaces in the public API will introduce an unfortunate
> inconsistency. The other concern is that namespaces are not well supported
> yet by the moc and the meta-type system.
> 
> For your response to the idea of experimenting with namespaces I do get the
> impression that you don't think that it is possible to introduce namespaces
> globally. Is that impression true?

I'm not sure I understand what you mean with "globally". I'm quite certain 
that Qt cannot move to the use of namespaces in a SC way. Not if the types are 
actually namespaced. You can, of course, say

    namespace QtCore { using Object = ::QObject; }

in every header file, but that's rather ridiculously inconsistent as every API 
user will choose differently between QtCore::Object and QObject.

> In the event of it being true, does that mean that in your opinion we have
> no choice but _do_ have some modules use namespaces in the API and others
> don't?

_I_ have no problem breaking SC come Qt 6 and move to either QtCore::Object or 
QtCore::QObject globally. You need to ask those who don't think a SC breakage 
of that dimension is acceptable for how they will _ever_ introduce namespaces 
into existing libraries, then. At the same time, I don't see why a new module 
shouldn't use the QtModule namespace from its inception - saves porting come 
Qt 6.

> > That side might be the vocal majority, too, tramping over the silent
> > majority, since I note that QtC is full of namespaces.
> 
> How does Qt related to QtC when the context is the public framework API?

You snipped where I say that I consider QtC the second-biggest internal 
producer of Qt-ish API (for plugins, say), after Qt itself.

But if you don't agree, then s/QtC/KDE/.

Thanks,
Marc


-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts



More information about the Development mailing list