[Development] Some Qt3D feedback

[Marc Mutz]

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. If you ban namespaces based on this, you need to ban nested 
types (e.g. error enums), too.

> * 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.

> * 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).

> * 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.

[...]
> At the same time, I think we should start experimenting with namespaces
> for Qt types. A way to do that that doesn’t disrupt current Qt development
> is by adding headers that put the types into namespaces:
> 
> --
> #include <QtCoreNamespace>
> 
> QtCoreNamespace:
> 
> class QObject;
> namespace QtCore { // or should this simply be Qt?
>     using ::QObject as Object;

This will exacerbate the problems you mentioned before, since every type will 
have two names, and there goes consistency...


>     // or
>     class Object : public QObject {
> 	using QObject::QObject;
>     }

This requires C++11 and makes Qt::Object and QObject distinct types. In 
particular, a cast from QLineEdit to Qt::Object is invalid, as QLineEdit is-
not-a Qt::Object. It also doesn't work for value tyoes.


> 
> Not sure this would work perfectly,

it wouldn't.

> but it might be worth a try :)

it isn't.

I'm sorry, but this mail contains no arguments against *namespaces*. It 
contains _some_ arguments against *nested types*, but Qt already widely 
violates that.

Curiously, you didn't list any pro-namespace arguments. I don't know what to 
make of this, but I fear that a decision is being made based solely on 
arguments from one side.

That side might be the vocal majority, too, tramping over the silent majority, 
since I note that QtC is full of namespaces.

Roughly one per library after a quick grep.

If name prefixing is The Way To Go, I wonder why QtC, as the biggest internal 
consumer, and second-biggest producer of Qt API, didn't choose it for its own 
internal structure...?

*And* they are using using directives all over the place. More than 2000. 
Maybe the devs over there got tired of typing QtCreatorCMakeProjectManager.... 
and QtCreatorCoreInternalDesignModeCoreListener? Maybe QtC already *has* the 
experience with namespaces we think we first needed to gather?

But after all I read from the proponents of name prefixing so far, we rather 
need to send the whole QtC bunch to the asylum because they've clearly backed 
themselves into a corner and can't possibly understand their code anymore. :)

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