On Thursday 18 June 2015 12:49:40 Koehne Kai wrote: > > -----Original Message----- > > From: development-bounces+kai.koehne=theqtcompany.com@qt- > > project.org [mailto:development- > > bounces+kai.koehne=theqtcompany....@qt-project.org] On Behalf Of > > Marc Mutz > > Sent: Thursday, June 18, 2015 3:08 PM > > To: development@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.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development