KDE 4 namespaces
klingens at kde.org
Mon May 9 21:01:59 BST 2005
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
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.
More information about the kde-core-devel