KDE 4 namespaces

[Martijn Klingens]

On Monday 09 May 2005 20:21, Fred Schaettgen wrote:
> Maybe I'm comparing apples and oranges, but Ilkka really has a point here.

We all know the advantages of namespaces.

However, we're not doing an academic excercise to come up with the best 
possible API, nor are we designing a completely new library from the ground 
up.

What we need here is pragmatism, and a balance between several mixed 
interests. Some of these interests are, in no particular order:

* Maintain existing API as much as possible to lower the porting effort (if it
   ain't broke...). This is especially important from a commercial point of
   view if we want to attract more ISVs to KDE-the-API.

* Stay consistent with our main base library (Qt), API-wise

* Don't hurt performance a lot with longer and more symbol names

* Avoid symbol clashes e.g. by namespacing, or K-prefixing

* Write clean and readable code and APIs

This list is by no means meant to be complete, but should be a nice start.

Although namespaces are nice, and I'm happily using them in KExtProcess, I 
don't think they are a good idea to retrofit them on most of our existing 
code. libkdecore and libkdeui aren't all that large, and so far I go with 
David's proposal to namespace our more specialized classes (KParts, KIO, ...) 
and keep the existing scheme for the core classes.

-- 
Martijn