Namespaces in libkdecore

Scott Wheeler wheeler at
Sun May 2 16:56:57 BST 2004

Hash: SHA1

On Sunday 02 May 2004 16:48, Frerich Raabe wrote:

> I read that response already and after reading it I was even more convinced 
> that the reasoning is too weak. Please correct me if I'm wrong but

Too weak for what?  I'm really not trying to make a case for namespaces 
here.  ;-)  I was just responding to Thiago's message that if one did want to 
use namespaces and maintain source compatibility that it was not particularly 
> 1.) "If you've worked with namespace'd libraries before, the K-prefix looks 
> ugly."

Well, again, please don't nitpick the logic out of context -- this was the 
responce to "namespaces are ugly".  If you're going to throw one out you have 
to throw both out.  I think it's fair to say that some people think 
namespaces are ugly; others think using a prefix to every class is ugly.  ;-)

> 2.) "I see that some (arguably newer) stuff in KDE uses namespaces already 
> and I'd like to standardize on whether we go for a namespace or not."

Well, yes, I still stand by this.  I don't like having part of kdelibs using 
namespaces and the other not.  If we decide not to use namespaces through all 
of kdelibs then I'd like to rearrange the parts that currently are.

What I'm asking is why we have most of khtml, kjs, kresources, kdeinterfaces, 
kabc and kparts using namespaces, but not kdecore and kdeui.  KIO is just a 
mess with half of the classes using namespaces and the other half not.

> FWIW, the vast majority of kdelibs classes are at global namespace scope,

I haven't counted, but it's certainly not a vast majority -- and I'm not even 
sure that it's a majority.  The more "special purpose" libs tend to be in 

> there's no "Uncertainity about whether something is in a namespace or not" 
> problem at all, and all the libraries which are scattered across the KDE 
> modules (think kdepim) are from my POV quite independant anyway and free to 
> do whatever floats the author's boat.

Well, "do what you want" works to an extent for coding style, but I think on 
matters of API there are less significant issues that we've standardized on 
(say for instance passing a QString by reference rather than value, even 
though they're basically both just a copying a pointer or not prefixing out 
accessors with "get").

I'd like to see concistancy here too.

- -Scott
- -- 
For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled. 
- --Richard Feynman
Version: GnuPG v1.0.7 (GNU/Linux)


More information about the kde-core-devel mailing list