[Development] Some Qt3D feedback

[Knoll Lars]

On 15/06/15 12:27, "development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of Simon Hausmann" <development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of simon.hausmann at theqtcompany.com> wrote:

>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.

I'd agree with this. 

Btw, if we use namespaces, then I think that using a Q prefix on the inner classes is wrong.

Qt3D::Parameter is much better to read than Qt3D::Qparameter. Duplicating the 'Q' feels like the worst of both worlds to me. Not duplicating it would be more consistent with other things such as inner classes used in other places or enums and functions inside namespaces.

Code written without a using directive, would feel somewhat similar to existing Qt code. Unfortunately, it would break badly if people wrote a using declaration at the beginning of their file. I guess that's where the idea of using a Q on the inner class came from. 

So if the namespace is relatively short, this could be done. But if we advocate against using directives, then are we actually a lot better than using class name prefixing? Is Qt3D::Parameter better than Q3DParameter?

Cheers,
Lars

>
>> >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
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development