[Development] Some Qt3D feedback

[Marc Mutz]

On Thursday 18 June 2015 22:36:01 Matthew Woehlke wrote:
> On 2015-06-18 16:33, Marc Mutz wrote:
> > On Thursday 18 June 2015 18:16:30 Matthew Woehlke wrote:
> >>> If you step back a bit, you'll notice that both <QtGlobal> and
> >>> <QtNumeric>, as  well as <QtNamespace> are big, fat, mistakes.
> >> 
> >> Why? How can QtNumeric, in particular, be a mistake unless qnumeric.h is
> >> also a mistake?
> > 
> > because <QtFoo> is the header that brings in all of module Qt Foo. And
> > neither Qt{Global,Numeric,Namespace} fit that description. Neither does
> > QtConcurrent{Run,Map}, btw.
> 
> Neither does <QObject>. Whether or not <QObject> should be allowed (vs.
> <QtCore/QObject>) is an interesting discussion, but not one I was trying
> to make.
> 
> I think we're arguing for different points. It's not the specific name
> that matters to me as that there is *some* header which is named
> according to modern C++ convention (in particular, no ".h"). If we have
> those for e.g. <QObject>, then IMO we should have them for *all* public
> headers. Or we shouldn't have them at all.
> 
> I agree that having modules and conceptual groups use the same naming
> convention is unfortunate, but I disagree that not providing
> modern-named headers *at all* is the correct solution to that problem.

   <Q_t_Foo>     - module: <QtCore>, <QtGui>, <QtWidgets>
   <Q__Foo>      - class: <QObject>, <QString>, <QLineEdit>
   <Q_t_Global>  - NOT a module (-> mistake)
   <Q_t_Numeric> - NOT a module (-> mistake)
   <Q_t_ConcurrentRun>
                 - NOT a module (-> mistake)
   <Q__Test>     - NOT a class  (-> mistake)

<QObject> does not stand for <qobject.h>. It stands for the class QObject. 
That's why <QSignalBlocker> also resolves to <qobject.h>.

So the question boils down to: If we have QFoo for classes and QtFoo for 
modules, do we need sans-.h headers for other entities? Namespaces? Enums? And 
I'd say no. If you say yes, then that's fine. Propose a naming convention for 
headers for enums (could use the convention for classes, as enums and classes 
share a namespace) and free functions (which I'd propose you put either into a 
class header that's related to the free function, or else into a 
q(t?foo(global|namespace|funtions).h that gets included in every Qt Foo class- 
and thus module header, but doesn't have its own sans-.h header.

People like you that want to optimize includes can still use the .h-header 
directly.

API design principle: make common tasks easy to use and other tasks possible. 
Perfect example. If you stray from QFoo means class, QtFoo means module, you 
make the common task hard. After all these years, I still have to look up 
whether to include <QtTest> or <QTest>. _This_ is a _real_ inconsistency. 
Namespaces aren't (they'd make QtCore::QObject consistent with 
<QtCore/QObject>!).

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