KDE 4 namespaces

Richard Smith kde at metafoo.co.uk
Mon May 9 23:47:43 BST 2005


On Monday 09 May 2005 00:57, Thiago Macieira wrote:
> with KDE 4 porting now imminent, I thought it was time to start the
> discussion on namespaces.
> The main drivers for using namespaces are:
> - less namespace pollution, leading to less chance of symbol duplication

If we do go the route of namespaces (which I think would be a good thing), I'd 
like to suggest we call our top-level namespace KDE40, and put

namespace KDE4 = KDE40;
namespace KDE = KDE4;

in some suitable header file. This means that processes will be able to have 
KDE4 and KDE5 (!) libraries in the same address space (which is not as crazy 
as it sounds, I promise). Plus, when KDE4.1 comes along, it means we can do 
funky things like this:

namespace KDE40
	class MyClass {/*...*/};

namespace KDE41
	using namespace KDE40;
	class MyClass {/*source-compatible, but not BC*/};

namespace KDE4 = KDE41;

and get away with making some (non-BC but source-compatible) changes we 
previously couldn't. I'm not yet convinced of whether this is a practical 

> 2) Two-level naming
>   We should avoid creating namespaces inside namespaces, except for the
>   top-level KDE namespace.

I'd be interested in seeing justification for this. In my experience, people 
use a lot of using-directives in the presence of namespaces. At work, we use 
namespaces three or four levels deep, and it doesn't cause any problems (in 
fact, it's helpful).

> These are the proposed namespaces:
>   KDE::Core   (the root namespace)

Why not use the namespace "KDE" for this? Given that I expect people will want 
to type at most one level of namespacing for the things they use often, I'd 
rather see KDE::StandardDirs than Core::StandardDirs.

> Namespace KDE::IPC
> ------------------
> Uses: KDE::Core, KDE::Network
> This namespace contains the Inter-Process Communication classes, or
> DCOP/DBUS/alike.
> Questions:
> - Will KDE::Core require this? If so, must be moved up, maybe to
>   KDE::Core::IPC (violation of rule #2), or be left as a non-KDE
>   namespace, like DCOP.

Best if KDE::Core didn't depend on KDE::IPC. Else KDE::Network depends on 
KDE::Core depends on KDE::IPC depends on KDE::Network.

More information about the kde-core-devel mailing list