Namespace hierarchies

[Jeff Mitchell]

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

Which is why I suggested dropping that 2nd part. But the namespaces
aren't necessarily limited to one item, such as Collections which
contains Collection, QueryMaker, and CollectionLocation. These are
grouped together because they are interdependent (in terms of both
ideology and code). You could fan those each out to top-level namespaces
but if you do that for each module you'll end up with a *lot* of
top-level namespaces. I think the current namespaces are a decent
balance of clarity vs. promiscuity.

> (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?)

No, you don't technically need it, but it makes the code much more
fragmented and conceptually more difficult to understand, especially for
new developers who may not understand where the different parts of the
code are being sourced from. You can now look at
Collections::SqlCollection and know that the base interface will be in
core/collections and the implementation somewhere under
core-implementations/collections (unless it's the top-level
Collections::Collection, but that's probably a decent trade-off to
remove one level of namespacing). Point being, that's valuable.

(There are some other namespaces peppered around the code but they're
mainly self-contained, except for the sprawling Amarok:: and The::).

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

We could shorten that if need be, perhaps by having only the
capital-letter initials for all but the final part of the namespace. It
may be a fair compromise between the debug output and the code clarity
(and that might be a good idea in terms of debug output verbosity anyways).

--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/cf235ada/attachment.sig