[Development] Some Qt3D feedback

[Stephen Kelly]

Knoll Lars wrote:

> * Generic and duplicated names from different namespaces can
> easily lead to confusion when reading code.

... and when searching about information about a class by unqualified name. 
'QTransform' is now ambiguous to google. If the namespace route is used for 
existing modules in the future (for consistency for example), then we'll end 
up with lots more of that: 'QNode' in the 'QSG' and 'Qt3D' namespaces, 
'QComponent' in the 'QQml' and 'Qt3D' namespaces etc.

I don't at all buy the argument that IDEs can know and show the fully 
qualified name and there is therefore no problem. A lot of the time people 
are reading code on websites/github/gerrit/code review tools/Stack Overflow 
etc and those typically do not provide context, except if by chance.

> * class name prefixing is a widely used and understood scheme by our
> users. Do we really want an inconsistency now in one place? I don’t think
> we have enough arguments to actually go down that route.

Right. That's exactly what started this thread.

> So what do we do with Qt 3D? For 5.5, we’re too late to do any changes.

I do not see the logic in the claim that it is too late for Qt 5.5 but not 
too late for Qt 5.6.

> But we’re talking about a Tech Preview here, so we can use it to collect
> some feedback on the namespace usage in there. We will however need to
> decide rather quickly whether we want to keep it or revert to regular Qt
> style class name prefixing for 5.6. I’m currently leaning towards the
> latter.

I agree with ossi that it is unrealistic/dishonest to expect a name 
consistency change like this to be done after the Qt 5.5 release. I will be 
extremely surprised if something like this changes after Qt 5.5 and before 
Qt 5.6. With the help of some sed :) :

 We couldn’t make things work in a source compatible way. Moving from 
 Qt3D::QTransform to Q3DTransform is not something you could do in a 
 transparent way. We could think about using a 'typedef Q3D::QTransform 
 QTransform’ for compatibility. But it would break things such as forward 
 declarations and typedefs.

The 'technical preview' label won't help. No one will treat the new module 
any differently. You will not be able to change the names. 

You wouldn't even bump the version of Enginio to fix the multitude of 
inconsistencies in that, even though the different version of it was 
*supposed* to make such changes and repairs possible. I don't see any way 
you would change all these Qt3D names.

But at least we'll get some years of experience and possibly feedback on the 
issue, and find a direction to go for consistency later.

*** Change of topic.

It seems that most people, but not everyone, in the discussion see the 
inconsistency and there are good reasons that it is not a good thing. It is 
also clear that now is not the right time to discuss those reasons, because 
we are discussing a decision that was made and committed to already in the 
past, instead of discussing something proposed for the future. 

The reasons for changing the use of the namespace were not compelling enough 
in their own to impel change when I first raised them a week ago. We needed 
a week for people to come out of the woodwork and give their view on whether 
there is inconsistency introduced (not everyone sees inconsistency here) and 
whether that is a good or bad thing.

This is another indication (in addition to the fact that new modules are not 
part of headerdiff review) that Qt probably needs to do some thinking about 
how new modules are discusssed/reviewed, so that these things can be 
resolved when there is time to discuss them calmly. 

Thanks,

Steve.