[Development] Some Qt3D feedback

[Knoll Lars]

On 17/06/15 15:36, "development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of Marc Mutz" <development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of marc.mutz at kdab.com> 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. If you ban namespaces based on this, you need to ban nested 
>types (e.g. error enums), too.

It's a question of how often you face these issues. Inner classes are not that common in Qt and even less commonly passed through signals/slots.

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

True. That's a good way to enforce a fully qualified name inside the macro. I like it, as it helps fixing this in the general case. We should probably do that for 5.6, as it'll help catch coding errors at compile time.
>
>> * 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).

Could be that others have decided differently. But it's a decision we did take some years ago. But I personally don't think leaving out the prefixes leads to more readable code in the general case (where you mix a couple of different modules/namespaces).
>
>> * 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.

Most of those are single standalong libraries, not a large collection as we have here. So the preconditions are a bit different as well. 
>
>[...]
>> 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...

I was talking about experimenting, not making this part of any product. So convert some piece of code to see how things feel. Currently we have little experience how this would work with our multitude of libraries.
>
>
>>     // 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.

So what are the arguments from your point of view then? Apart from namespaces being in fashion.
>
>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?

Maybe. But if so we haven't clearly heard statements from that side. But please also remember that there are differences between doing APIs/frameworks and doing apps.

Cheers,
Lars

>
>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
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development