Namespaces in libkdecore
wheeler at kde.org
Sun May 2 16:56:57 BST 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
- --Richard Feynman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-core-devel