On 09.07.2013, at 13:35, Oswald Buddenhagen <[email protected]> wrote:
> On Tue, Jul 09, 2013 at 12:51:51PM +0200, Ziller Eike wrote: >> >> On 09.07.2013, at 11:11, Oswald Buddenhagen <[email protected]> >> wrote: >> >>> On Mon, Jul 08, 2013 at 09:01:56PM +0200, André Pönitz wrote: >>>> (b) Lower case outermost namespace >>>> Contra: >>>> - It works as it is. >>>> >>> - it's non-qt >> >> I don't see the point, Qt doesn't use namespaces at all. So going the Qt way >> would be to remove all namespacing... >> > orly? > namespace Ui (any uic-generated file) > namespace QtPrivate (lots of internals, obviously) > namespace QDBus > namespace QTest > namespace QtConcurrent > namespace QPatternist > > i got bored at this point … Ok, there are. They are just not widely used. So the requirement that "components" in Qt Creator are in a namespace is already non-Qt. I don't see a problem with deviating from Qt's "convention" in that case, which doesn't seem to be used very consistently in Qt either (e.g. QtPrivate seems to be only used in QtConcurrent and QtCore at all, all others don't seem to namespace their private API) >>> to solve the clash problem, there are two approaches: >>> - use an additional convention (ugly) >>> - FooNames::Foo >>> - Foo::FooClass >>> - remove the redundancy >>> - Foo::Plugin >> >> The clash is with things like CppEditor::CppEditor. >> > maybe the problem is the namespace name then? > the vcs plugins don't have any suffix. maybe the same should be done for > the laguage plugins. CppEditor is not one of the language plugins, that is CppTools. CppEditor is really the plugin that contains only all the editor related code. Similar with BinEditor::BinEditor, DiffEditor::DiffEditor. > or, because the namespace belongs to the plugin, name it > CppEditorPlugin. of course this would then produce > CppEditorPlugin::Plugin … That would lead to all namespaces having the redundant "Plugin" postfix. > yet another option would be "big endian" notation for the plugin names: > EditorCpp, VcsGit, ProjectManagerQmake, etc. a bit unnatural, but sorts > nicely (easier to catch omissions during refactoring), and is profoundly > distinct from the class naming convention. I just don't know why to go through hoops instead of just going for lowercase namespaces. These would also be visually profoundly distinct from the class naming. It looks to me like the only "contra" against lowercase namespaces that we are currently talking about is "it's non-qt" which I find arguable. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
