[Development] Some Qt3D feedback

[Julien Blanc]

Le jeudi 18 juin 2015 à 13:19 +0200, Simon Hausmann a écrit : 

> On Thursday, June 18, 2015 12:45:53 PM Marc Mutz wrote:
> [...]
> > 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.
> 
> Let me give you a concrete example of where "no trouble whatsoever" does not 
> hold in my opinion:
> 
> Qt3D has a QKeyboardInput class:
> 
> namespace Qt3D {
> 
> class QKeyboardInput: public QComponent
> {
>     ...
> Q_SIGNALS:
>     void leftPressed(Q3DKeyEvent *event);
>     ...
> };
> 
> The Q3DKeyEvent class is declared in a namespace as well:
> 
> namespace Qt3D {
> class Q3DKeyEvent : public QObject
> {
>     ...
> };
> }


Then you shouldn’t do that. You should use the fully qualified name in
your signal definition. IIRC the doc is clear on this.


> 
> The moc generated code for QKeyboardInput stores "Q3DKeyEvent*" as
> type name for the parameter of the leftPressed signal.


Then the question is : can moc be improved to trigger an error (or
generate C++ code that triggers an explicit error, via static_assert for
example) when defining such signals ?

Because yes, that’s an issue, and a troublesome one. Marc told earlier
about the SC break : it’s easy to deal with SC break that triggers
compile-time errors. But SC breaks that silently triggers bugs are much
more a burden. There is a strong precondition imho before doing a move
to namespace, which is being able to detect all connection / method
invocation / ... errors. Because that’s the kind of SC break that will
inevitably occur.

Regards,

Julien

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150618/81b6bf35/attachment.html>