[Development] Some Qt3D feedback

Sean Harmer sean.harmer at kdab.com
Mon Jun 15 14:01:04 CEST 2015


On 15/06/2015 12:49, Knoll Lars wrote:
> 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?

Right. The reasons for duplicating the Q were:

* The existing syncqt.pl works
* Code written with a using directive still looks like Qt code

Although we could recommend people to not use using directives we can't 
enforce it (nor should we) so the expense of the single repeated Q 
seemed like the least onerous option. Not ideal, but a compromise from 
the other options.

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




More information about the Development mailing list