[Development] Some Qt3D feedback

[Sean Harmer]

Hi,

On Thursday 11 June 2015 23:15:20 André Pönitz wrote:
> Specifically, for item #6:
> 
>     [Stephen]
> 
>     > Qt3DParamter might be better *and* more consistent.
>     > Similar applies to other classes.
> 
>     [Sean]
>     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.
>     [...]
>     Name spaces are supported everywhere these days so why not just use
>     them, especially in a new add-on module?
> 
> That's exactly the kind of situation I was referring to in my previous
> mail: This is *intentionally* introducing API inconsistency. It does not
> really matter to me whether "poor-man's prefix name spacing" is
> unfashionable or "we" consider it bad. It is simply *inconsistent* with
> more than 200 of existing exported QQuick*, QSG* and QQml* classes.

The majority of those QQuick*, QSG*, and QQml* classes are not exported or 
documented as internal so the 200 number is overstated.

Also, as Marc pointed out, those class names are themselves inconsistent with 
other classes within QtCore, QtNetwork, QtGui etc. As I replied earlier, once 
you add a using namespace Qt3D to a translation unit the Qt3D actually looks 
more consistent with other parts of Qt than using QQuick* etc. with the 
proviso that you need to disambiguate in the case of collisions.

Furthermore, it is inconsistent to want to push forwards with the allowable 
set of C++ 11/14/whatever features which will mean dropping support for older 
compilers and platforms, yet denying the ability to evolve our API beyond the 
1990's paradigm. Dropping support for older compilers is a much harder pill to 
swallow than asking people to use a namespace in a new addon module. 

I'm not arguing that namespaces should be used because they are fashionable. 
I'm arguing they should be used because this is the intended use case of a 
very mature language feature. If we can't try new things out in new addon 
modules, then where can we try them?

I propose we try keeping the Qt3D namespace. I'm sure our user base, which is 
made up of intelligent people, can figure out how to resolve any issues that 
arise due to the presence of the namespace very quickly then move on with no 
more difficulty than with any other areas of Qt.

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions