[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amarok-devel
Subject:    Re: Namespace hierarchies
From:       Erik Hovland <erik () hovland ! org>
Date:       2010-03-29 20:44:19
Message-ID: a33aad7f1003291344l399f925ar8a9ecb889b4d07c0 () mail ! gmail ! com
[Download RAW message or body]

> ...continuing a discussion started on IRC.
>
> In core we have several new namespaces: Meta, Collections, Podcasts,
> Playlists, ...
>
> There are 2 options for namespace hierarchies in the implementations:
>
> 1) grouped by implementation backend:
> ex. for Sql
> Sql::Collecion
> Sql::Meta::Track
> Sql::Playlist
> Sql::Podcast::Episode
>
> 2) or by core namespace:
> Collections::SqlCollection
> Meta::Sql::Track
> Playlists::Sql::Playlist
> Podcasts::Sql::Episode
>
> Before any more big commits are made we should discuss.
>
> Note that we already use both in a way:
> - Podcasts::SqlPodcastChannel though it's generally agreed that this
> is misuse of the namespace.
> - MetaFile::Track
>
> I think 1) is superior because it saves massively on typing (ex):
>
> using namespace Sql:::Podcast;
>
> QString
> Channel::title()
> {}

I don't consider a reduction in typing to be a very good criteria on how
namespaces should be used. Are there any other reasons to use 1 over 2? This
issue can be mitigated using namespace aliases.

namespace SPC = Sql::Podcast;

or in the case of 2:

namespace SPC = Podcast::Sql;

This has the added benefit of no implied namespace that "using" always seems
to bring w/ it.

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.

E

-- 
Erik Hovland
erik@hovland.org
http://hovland.org/
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
[prev in list] [next in list] [prev in thread] [next in thread]