[RFC] Solid and use of namespaces

[Kevin Ottens]

Hello list,

As some of you already know, I'm working on Solid [S], and the current classes 
are in their own namespace (Solid).

The current code is the most "neutral" part, it handles the hardware 
discovery. I'm planning to add more specialized classes to handle specific 
tasks, namely network and power management.

Since my current idea is to put those more specialized classes in their own 
subnamespaces, I'm posting here to be sure the solution I'll choose regarding 
namespaces won't get in the way of application developers.

By using nesting, I will introduce Solid::Network and Solid::Power namespaces. 
It then raises some questions regarding the classes naming. For example, I'll 
have a "manager" class regarding power management, I can basically name it:
1) Solid::Power::Manager, which leads to the fact that you can't do "using 
namespace Solid::Power", "Manager" would become a too general name
2) Solid::Power::PowerManager, which obviously introduces naming redundancy, 
but you could do "using namespace Solid::Power".

Opinions are welcome, in particular I'd like to have reactions regarding:
1) The use of those nested namespaces, good or bad? better keep a flat 
organization (everything in a Solid namespace)? Currently I dislike this 
idea, but well nothing is set in stone yet, so if good arguments are provided 
I can change my mind.
2) The names of the nested namespaces? If I go this way, do the 
names "Network" and "Power" convey enough information?
3) Class naming in those namespaces? for example should I go for 
Power::Manager or Power::PowerManager? That's the main reason why I'm asking 
for comments, it'll have an impact on the ease of use of those classes.
4) Anything I could have missed.

Regards.

[S] http://solid.kde.org
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060521/ba75c920/attachment.sig>