[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE 4 namespaces
From:       Martijn Klingens <klingens () kde ! org>
Date:       2005-05-09 20:01:59
Message-ID: 200505092202.00094.klingens () kde ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]