[Development] Some Qt3D feedback

[Simon Hausmann]

On Monday, June 15, 2015 10:18:38 AM Marc Mutz wrote:
[...]
> > > QtConcurrent
> > 
> > A namespace for functions only, no public classes within.
> > 
> > > QTest
> > 
> > A namespace for functions only, no public classes within.
> 
> _That_ argument again... :)
> 
> Could you explain to me why you think that classes are different from
> functions, pleaae?

When reading the code they look different compared to other Qt APIs:

	QtConcurrent::run(pool, ...)

is consistent with class functions in other parts of Qt from the way they look 
when reading code. We do have those. Classes in name spaces look different on 
the other hand:

    Qt3D::QParameter param = ...;

This class usage is different to me than other usages in Qt. I do believe that 
we have a hand full of "inner" classes, for example

    QAbstractTextDocumentLayout::Selection

but I feel those are the minority and they are not prefixed with a "Q".

I understand that I can write

   QParameter param = ...

with the help of "using namespace Qt3D;" further up in the file. But this is 
where the inconsistency comes in, because other Qt modules currently don't 
require the use of "using" in order to achieve the similarity here. At the 
same time when I see "QParameter" as plain type name, I feel that it is a 
"vague" name and I would prefer a more precise term that relates more to the 
use case at hand.

> >From a technical POV, the classes themselves have internal linkage. It's
> >their
> member functions who have external linkage and are exported.
> 
> And run(QThreadPool*, ...) forms as much part of QThreadPool's API as does
> QThreadPool::run(QRunnable*). All non-member functions that mention a type
> in their paramater list are logically part of the type. And C++ enforces
> that (with ADL).
> 
> There's simply no difference between a class in a namespace and a free
> function in a namespace, except, of course, that after a using directive,
> you still see the class name (abridged) while you don't see the namespace
> for free functions.
> 
> So _if_ there's a qualitative difference between free functions and classes
> in namespaces, it's the free function case that should be controversial,
> no?

Yes, from a technical point of view it's easy to argue that free functions are 
"controversial". But I'm not looking at this from a technical point of view. 
>From all that I can tell, this is purely a question of aesthetics, hardly 
something that can be decided based on numbers or other technical figures.


Simon