From: Pavol Droba (droba_at_[hidden])
Date: 2004-03-30 14:16:22
Hi,
On Tue, Mar 30, 2004 at 07:09:41PM +0200, Joaqu?n M? L?pez Mu?oz wrote:
>
> NAMESPACE
> * Proposal: boost::container::multi_index
> * Rationale: The name suggests what the library is about and
> does not clash with the name of the container. Preferred
> to multiindex as English seems to like the former better.
> In favor of multi_index: Rob, Pavel (underscore-less variant),
> Arkadiy (for the container instead), Jeff, Thorsten, Paul, Matthew
> (only if pushed into boost::container).
> Alternatives: non-descriptive name (Tom), multi_indexed_containers.
> * Why inside boost::container? Seems like there's a general
> move to 2nd level namespaces, and this in particular
> saves us from repeating "container" in the library namespace
> itself. If anything, being the only library inside boost::container
> does not hurt. I've scanned the posts and these are the reviewers'
> opinions about this subject matter:
> In favor of pushing into boost::container: Matthew, Joerg
> Against: Dave
> Not sure: Jeff
> Don't care: Gary, Darren
>
I have just one remark about the namespace usage. IMHO it is an overkill to
provide a special namespace for every container.
I think, that putting this all containers into boost::container namespace
is verbose enough.
There has been very similar discussion about the algorithm namespace
(namely the string algorithm library). Current situation is that everything
resides in boost::algorithm namespace and interface names are lifted to boost
namespace. This model has been settled as a reasonable compromise.
It is worth to mention, that there are generaty more free stading names in algorithm
libraries than in the container ones. So if the name-clashing problem is not here,
I don't see it in container case.
Last argument in favor of proposal I have mentioned is to have one uniform setup
in the boost if possible. If the algorithm part is already settled, containers should
follow.
Regards,
Pavol