[Development] Some Qt3D feedback

[André Pönitz]

On Thu, Jun 18, 2015 at 09:22:07AM +0100, Sean Harmer wrote:
> On Thursday 18 Jun 2015 09:18:15 Giuseppe D'Angelo wrote:
> > On Thu, Jun 18, 2015 at 9:08 AM, Simon Hausmann
> > 
> > <simon.hausmann at theqtcompany.com> wrote:
> > > Or would the idea be to place the Q_DECLARE_METATYPE outside of the
> > > namespace?
> > Why "the idea"? It's the way it's supposed to be used right now.
> 
> Indeed, and we've been using it extensively and have not encountered any 
> blockers with moc or the metatype system thus far. So in our experience there 
> are no technical blockers.
> 
> Qt3D is only a tech preview in 5.5 so we are free to change it at will. I'd 
> suggest we leave it as is for 5.5.0. For 5.5.1 I'd propose we resolve the 
> small namespace inconsistencies between the QML and C++ APIs as discussed 
> elsewhere in this thread and see how users get on with that with a view to 
> using it as a way of testing the waters for a larger rollout of namespaces for 
> Qt 6. I'd propose to do this in the way that was tabled during the development 
> of Qt5 but which we failed to enact upon.
> 
> For a new module I really don't see the small inconsistency c.f. the rest of 
> Qt of using namespaces as an issue - especially given the other 
> inconsistencies that have been discussed. Users will cope with this, I'm sure. 

People cope with air pollution, too. That's not a good reason to increase it.

> I am happy to document this on the wiki as guideline proposal for new modules 
> as Sze-Howe suggested.

Just sticking to the existing patterns would save you from documenting
the deviatation and the users from wondering why the should search for
documentation on deviations from prior arts in some wiki.

So far no reason was given in favour of the additional inconsistencies
that went beyond "I think it is posh" and "I want to have fun playing
with the Qt API".

There has been no answer on how to prevent forseeable additional bikeshedding
on the use of 'using' and resulting additional inconsistencies in the code base.

All the talk about "the compiler will tell you when there's a problem"
entirely ignores the fact that the better part of programming is done
on syntactically incorrect translation units (while editing) or in contexts
were there's not even something like a translation in reach (reviews on
gerrit, looking up documentation), or, in short, pardon my German: ist Unsinn.

I propose to not intentionally introduce more API inconsistencies and
ban all API experiments during the 5.x cycle unless they are well
guarded behind #ifdef-ery based on an opt-in configure switch or similar.

Andre'