KDE 4 namespaces
zander at kde.org
Fri May 13 13:04:24 BST 2005
On Monday 09 May 2005 01:57, Thiago Macieira wrote:
> with KDE 4 porting now imminent, I thought it was time to start the
> discussion on namespaces. If you've talked to me recently on the subject,
> you know I am pro-namespaces and would like to see everything deeply
I'm not sure how many people here know me; as I have been around KDE for
many years but I went away for some 5 years.
In that time I spent most of my programming work in Java. And as
you all know Java is using packages (aka namespaces) quite a lot, so I
thought I'd share my experiences a little. I mean; how many people in this
thread have 6 years (daily) experience with this stuff :)
Reading through this thread the consensus seems to be that namespaces are
really nice when you design a library, but the effort of refactoring
everything afterwards seems to be not worth it.
The biggest advantage to using namespaces is a global consistent naming
scheme. So everyone can follow a simple rule for finding a class without
searching the docs. For example in Java there is a rule that you should
have a plural name for a package (KDE::widget instead of KDE::widgets).
Clear naming rules means easier to find classes, no duplicate classnames or
clashes and naturally world piece as a result :)
The perfect situation for KDE would be one that has a very clear strategy on
naming. Where naming is the fully classified classname, i.e. including all
That can be achieved in a number of different ways; the proposal of Thiago
just mentions one of them. One that arguably is the worst since it takes a
lot of effort to get there from where we are now.
Random relevant notes:
a package (aka namespace) in Java tends to group together one specific set
of classes implemented for a specific purpose. Example; I use separate
model and widget packages to signify different usage of those classes.
I created a texteditor widget which has a total of about 20 classes and a
lengthy doc about usage of all those classes together. Its easier to
maintain if you place it in a subdir and at the same time put it in its own
package. Where the package is mostly used to avoid nameclashes. Naturally
the package-widget documentation option of javadoc also really shines here.
If kdelibs is to be divided into namespaces I'd really use a lot more then
the propsal shows. I.e. add; KDE:UI:Widget and KDE::UI::Model.
The advantages of namespaces over KClass naming is not really significant
and probably very personal anyway.
Since C++ misses the advantages of Java in usage of namespaces (friend
classes; package-protected-classes etc) I don't see how usage of namespaces
will really make a difference from a technical point of view.
I (still) really like to see a guideline for classnaming (the lack of one is
probably what lead to kio namespace problem) so all classes will be
consistent in their fully-specified names.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel