Namespace hierarchies

[Dan Meltzer]

On Mon, Mar 29, 2010 at 5:21 PM, Jeff Mitchell <mitchell at kde.org> wrote:
> 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

I'd rather drop the Collections than the Collection, I think.... I
know that a Collection is part of collections, it's a bit redundant.
(and, even more, would there be a sqlcollection anywhere besides
Collections? and if so, would there be another SqlCollection inside of
Collections but not part of Collection? do we need either level of
namespacing?)

One other place to think about the impact of increased verbosity is
debug output, DEBUG_BLOCK prints the fully namespaced name, and the
longer we make the name the less room there is for useful information.

Dan,
>
> 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
>
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>