KDE 4 namespaces

[Thomas Zander]

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
> namespaced.

Hi,

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 
its namespaces.

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.

My conclusion;
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.

Cheers!
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050513/6d963ec8/attachment.sig>