Namespace hierarchies

[Jeff Mitchell]

On 3/29/2010 4:44 PM, Erik Hovland wrote:
> The difficulty I see w/ option number 2 is that it could quickly lead to deep
> hierarchies. Deep hierarchies lead to less code sharing because the
> namespace barriers between them end up being barriers in the
> developers
> mind. But the scheme doesn't seem that bad at the current three levels. There
> is also the issue of class movement up and down the hierarchy. Developers
> end up spending too many cycles managing the namespace and not enough
> cycles working on code. namespaces should work for us. Which I think
> is the core issue of Bart's original post. I think option number 2
> does give a clearer
> picture of how the classes are actually structured.

I do too, which is why I like it.

It's true that you have to be careful of too deep nesting. Some corners
may have to be cut in that line of reasoning.

I think things like:

Collections::Collection::SqlCollection::SqlCollection
Collections::Collection::SqlCollection::SqlCollectionImpl
Collections::Collection::SqlCollection::SqlCollectionLocation

Are great because they are really descriptive, typing be damned (and as
you said using namespace commands reduce the typing significantly...that
being said, there are some benefits to being complete when possible).

In the above example the ::Collection:: part specifies which part of the
Collections namespace is being implemented (as opposed to QueryMaker or
CollectionLocation); but since there are relatively few higher-level
interfaces and the subclass names are descriptive, you could really just
cut to the chase:

Collections::SqlCollection::SqlCollection
Collections::SqlCollection::SqlCollectionImpl
Collections::SqlCollection::SqlCollectionLocation

Even when doing this single-level shortening, you do have to watch out
for things like:

Collections::MediaDeviceCollection::AudioCdCollection::AudioCdCollection
Collections::MediaDeviceCollection::AudioCdCollection::AudioCdCollectionLocation

It's certainly very descriptive, which is great -- you know exactly
where AudioCdCollection lies. But it's very long.

You could mitigate it by not grouping items by where they belong but by
what interfaces they actually implement (still throwing out the 2nd
level interface):

Collections::MediaDeviceCollection::AudioCdCollection
Collections::MediaDeviceCollectionLocation::AudioCdCollectionLocation

which has a further benefit that if there e.g. is no
MediaDeviceCollectionLocation, you can skip straight to the point:

Collections::MediaDeviceCollection::AudioCdCollection
Collections::AudioCdCollectionLocation

You can still get some fairly long things out of this, when there are
implementation classes defined (again, still throwing out the 2nd level
interface):

Capabilities::TrackCapabilityDelegate::TrackCapabilityDelegateImpl

but you certainly know what's going on...

A final point: this further refactoring of the namespaces is going to be
relatively quick and easy now that the top levels are done...in fact I'd
recommend it as a junior job, if we can find anybody interested.

I do think it'd be helpful to SoC students to have all of this done
before SoC starts.

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20100329/c2dd2f3d/attachment.sig