[Development] Some Qt3D feedback

[Sean Harmer]

Hi Steve,

On Wednesday 10 Jun 2015 21:03:32 Stephen Kelly wrote: 
> >> 5) Qt3D namespace
> >> 
> >> This is the first time that all classes in a library are in a namespace.
> >> Previously only enums (in various modules) and free functions (in
> >> QtConcurrent) have been put in namespaces.
> >> 
> >> In QtConcurrent, the module name also appears in the header file, but
> >> that is not followed by Qt3D libraries.
> >> 
> >> Given that Qt has never put classes in a namespace like this, is there
> >> something to be consistent about here?
> >> 
> >> 6) QParameter is a very generic name
> >> 
> >> I realise it is in a namespace, but still...
> >> 
> >> Qt3DParamter might be better *and* more consistent. Similar applies to
> >> other classes.
> > 
> > It's precisely because of these kinds of issues that we decided to use
> > namespaces in Qt3D rather than the poor-man's prefix name spacing.
> 
> I don't understand what you wrote. I assume when you wrote 'these kinds of
> issues' you didn't mean that "better *and* more consistent" are the 'kinds
> of issues'. What do you mean?

Better is a subjective term that depends upon the metrics being used. 
Qt3D::QParameter is meant to be generic - it translates through to uniforms, 
samplers etc inside of shaders which are generic. It seems cleaner to use that 
within a namespace than using clunky prefixes. Namespaces don't enforce the 
additional writing if using a 'using namespace Qt3D' construct, whereas 
prefixing does.

With a field as broad as 3D simulations (not just rendering) there is a very 
high probability of conflicts with other names in different domains. One we 
would already hit is QTransform.

With namespacing, you only need to disambiguate when needed.

In QML, using prefixes would also lead to more typing whereas we've been using 
QML namespaces to disambiguate where necessary - i.e. when we combine Qt3D and 
Qt Quick 2 in the same file.

That is my justification for "better", so that leaves consistency.

I admit Qt3D is being inconsistent with other modules. It is also a Qt Addon 
rather than an Essentials module and also a new module. Given the recent 
discussions on the ML at at the contributor summit about using new C++ 
features, we would like to use namespaces in Qt3D.

My understanding is that Qt traditionally doesn't use namespaces due to poor 
compiler support for them in the early days of Qt. Of course that may be an 
incorrect perception since I wasn't involved way back then.

So using namespaces from the point of view of allowable C++ features would 
seem to be OK given that some C++11 is also acceptable for new modules. Also 
the need to explicitly use namespaces is only required when disambiguating 
means the code reads similarly to existing non-namespaced modules.

> I would encourage a discussion of why this module needs namespaces when the
> rest of Qt gets by without them. There is certainly a consistency angle.
> Should all new modules use a namespace? Should the namespace correspond to
> the name of the repo the library it's in? Or should there be a namespace per
> library?
> 
> > If it's required to not use namespaces to be part of the Qt project then
> > we can of course change it. However, I would argue against doing so,
> > especially in the light of being able to use some more modern C++ features
> > in upcoming QT versions.
> 
> I don't know. As far as I know deciding to use a namespace for this one was
> done without discussion on the mailing list?

There has been at least some discussion of namespaces in the past. For e.g.

http://lists.qt-project.org/pipermail/development/2012-August/005580.html

And it's not like we've done this in secret.

> I'm encouraging discussion such as on the questions I raised above.
> 
> You're introducing inconsistency, so how will things be made consistent
> again in the future? What is the direction? What is the policy? What is done
> for new modules? What should be done for Qt 6? Everything in different
> namespaces? Or everything in a Qt6:: namespace? Or multiple namespaces?
> Qt6::Core::QString? Do you aim to see

No intentions beyond avoiding name clashes with Essentials modules without 
enforcing a bunch of extra typing on users. I'm happy to participate in a 
discussion about namespacing in the larger context of Qt for the future but I 
don't have any strong preference apart from not adding extra work to end users 
porting from Qt5 to Qt6.

>  using namespace Qt6::Core;
>  using namespace Qt6::Gui;
>  using namespace Qt6::Network;
>  using namespace Qt6::3D;
> 
> at the top of most translation units using Qt, as one sometimes sees for
> boost use? Is that the future of what Qt-using code will look like? Do you
> find Qt3D code readable without the Qt3D:: prefix? I don't know as I haven't
> written any. Do you discourage or encourage the use of
> 
>  using namespace Qt3D;

That's the pattern we've been using but imho it's up to the end user if they 
prefer to be explicit or to use this paradigm.

> All I know is that we now have inconsistency with this new module.
> 
> Then again, if anyone else on this mailing list thinks namespace consistency
> is relevant for Qt, they can also chime in. As they've not done so here, we
> can probably assume the community vibe is that namespace consistency isn't
> something to create or look for in Qt at this time.
> 
> You can start a thread/discussion if you wish :). I'm mostly curious what
> you think this means for the rest of Qt and the future of Qt.
> 
> > Name spaces are supported everywhere these days
> > so why not just use them, especially in a new add-on module?
> 
> I don't know that that was ever the reason Qt doesn't put everything in a
> namespace. If it was we would have changed it for Qt 5.0.

I seem to recall it was raised as an option at one point during Qt 5.0.0 
development but discounted to avoid additional porting pain.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts