[Development] Some Qt3D feedback

Simon Hausmann simon.hausmann at theqtcompany.com
Thu Jun 18 09:08:18 CEST 2015


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?

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

> > * 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.
 
> > * 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?
 
> [...]
> 
> > 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.

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)


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?

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?

> 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?
 

Simon



More information about the Development mailing list