[Development] Qt & Namespaces (was: RE: Some Qt3D feedback)

Milian Wolff milian.wolff at kdab.com
Thu Jun 18 15:16:06 CEST 2015


On Thursday 18 June 2015 12:49:40 Koehne Kai wrote:
> > -----Original Message-----
> > From: development-bounces+kai.koehne=theqtcompany.com at qt-
> > project.org [mailto:development-
> > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of
> > Marc Mutz
> > Sent: Thursday, June 18, 2015 3:08 PM
> > To: development at qt-project.org
> > Subject: Re: [Development] Some Qt3D feedback
> > 
> > On Thursday 18 June 2015 12:51:01 Smith Martin wrote:
> > > Do you also advocate rules for using namespaces in Qt? What rules does
> > > KDE use?
> > 
> > I believe it's worth reading Sze Howe Koh's mails in this thread and the
> > last one (Oct 2013), even if the mails tend to be overwhelmingly full of
> > information :)
> > 
> > On a completely personal note, I'd find the following most natural:
> > 
> > 1. Each Qt Module "Qt Foo" (name used in docs), with soname
> > 
> >    Qt<MajorVersion>Foo, only exports symbols in namespace QtFoo,
> >    potentially with nested inline namespace V<MajorVersion>.
> 
> This has the advantage of being a very simple, mechanical rule. But it's
> also very burdensome ... You'll probably end up writing
> 
> using namespace QtCore;
> 
> in every single source file, since you almost certainly don't want to use
> QtCore::QString all over the place.
> 
> Now you could argue that QtCore is special, but then again the module
> contains something like "QState", which is such a generic name that you
> probably want to have it in a namespace.

And that is fine, no? I do the same in all the projects I work on that use 
namespaces.

> > 2. Free functions are not prefixed with 'q' (QtFoo::escape(), not
> > 
> >    QtFoo::qEscape()).
> > 
> > 3. Classes, I'm not so sure about the Q. Could leave it for better SC /
> > 
> >    branding, or only add a deprecated typedef Bar QBar (either insider the
> >    namespace or outside) for easier porting.
> 
> If there's one way to break almost every single line of Qt code out there,
> it's removing the 'Q'. Even if you mitigate this by typedef',s I just don't
> see that happening ...

Why would it break with a typedef? Forward declarations? One could go the 
other way around and have the non-Q versions as typedefs of the Q versions. 
And with Qt7 or so it could be removed altogether.

> So you end up with QQml::QQmlEngine. I like Q's , but that's a tad too much
> for my taste.

I agree. And QTest::qSleep is something I tripped over so many times... It 
still makes me angry whenever I write it.

> > 4. Includes:
> >    a. <QtFoo> includes the whole module (as is the case for QtCore, ...
> >    now)
> >    b. There's no <QtLike> include for just the namespace (with enums, free
> >    
> >       functions, etc). To get the namespace, users include any class from
> >       the
> >       module (much like no-one is using <QtGlobal> atm, but relies on any
> >       <QFoo> to include it indirectly).
> >    
> >    c. Class includes: <QtFoo/QClass> or /Class, depending on (3). Maybe
> >    
> >       <QClass> for backwards-compatibility, with a warning a la
> >       <strstream> on
> >       GCC.
> > 
> > 5. (most important) don't express a bias for QtFoo::Class vs. using
> > directives> 
> >    in the docs. That's _entirely_ up to the user. I'd even go so far as to
> >    leave that up to the individual developer in Qt implementations, while
> >    still demanding to following the style found in the file-under-edit, of
> >    course. In docs and examples, I'd tend to use fully-qualified names, if
> >    only for automatic qdoc linking, but if qdoc can cope (doxgen can), I'd
> >    use
> >    using directives in the examples/ subdir, at least.
> 
> Yeah well, not sure whether that's most important, but I actually agree:
> Namespaces in general are well understood, and we don't have to patronize
> our users about their exact use. They will make up their own minds, anyway.
> 
> My 2 cents: Adding namespaces carefully where they make sense is a good
> thing in the long run, and Qt 6 _might_ be a time where we could also touch
> existing modules to avoid clashes. But let's not overdo it. And renaming
> existing popular classes is IMO a non-starter.

I'd welcome Marc's proposal very much. And what he proposed has a way to stay 
backwards compatible.

Bye

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts



More information about the Development mailing list