[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