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

Smith Martin Martin.Smith at theqtcompany.com
Thu Jun 18 14:59:32 CEST 2015


Why not leave current Qt modules as they are, without namespaces and with the Q prefix on classes, and just introduce the option of adding a new module to Qt by putting it in a namespace named QtFoo without the Q prefix on class names, or adding it with no namespace and with the Q prefix on classes.

Converting existing modules to use namespaces seems like a lot of aggravation for not much gain.

martin
________________________________________
From: development-bounces+martin.smith=theqtcompany.com at qt-project.org <development-bounces+martin.smith=theqtcompany.com at qt-project.org> on behalf of Koehne Kai <Kai.Koehne at theqtcompany.com>
Sent: Thursday, June 18, 2015 2:49 PM
To: Marc Mutz; development at qt-project.org
Subject: [Development] Qt & Namespaces (was: RE:  Some Qt3D feedback)

> -----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.

> 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 ...

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

> 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.

Regards

Kai
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list