Re: [boost] [indexed_set] revised naming proposal

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-04-12 01:14:28

Daryle Walker ha escrito:

> On 4/10/04 5:13 PM, "JOAQUIN LOPEZ MU?Z" <joaquin_at_[hidden]> wrote:
>
> [SNIP]
> > NAMESPACE
> > * Proposal: boost::multi_index. This differs from
> > the previous proposal in which boost::container is
> > not used; rationale: resulting qualified ids would
> > be too long, which would force most users to use
> > namespace aliases (not a good thing, this has been
> > discused before in connection with Boost.Filesystem)
> > or apply using directives. Another reason is that a
> > good deal of preexisting Boost containers don't live
> > in boost::container and it does not seem such a
> > migration will ever take place.
> [TRUNCATE]
>
> But a lot of containers were made before the initiative for sub-namespaces.
> Some library has to volunteer to be the first of a new namespace.  Also,
> isn't "multi_index" longer than "container" (unless you were going to add an
> inner sub-namespace, which probably would be too much)?

The problem is that, regardless of whether the container is subsumed
into boost::container or not, it needs a namespace of its own, for the
several utility classes coming with the main class, like (to name a few)

ordered_unique,
ordered_non_unique,
sequenced,
index_list,
tag,
index
nth_index,
etc.

(there might be a couple of dozens or so of them, haven't counted them up.)
So, if we agree that we need a multi_index namespace the question can be
formulated as: should we use boost::multi_index or boost::container::multi_index?
My proposal for the former aims to keep qualified names reasonably short.

>  Would any other
> type besides your current ones ever qualify to go into a "multi_index"
> namespace?  We should limit the number of exclusive namespaces (unless the
> library is ridiculously huge, like Regex or Spirit).
>

The idea is that some types derived from the main container class
will be living into multi_index in the future. The first targeted
derived container is the infamous bidirectional map or bimap.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo