Re: [boost] Re: Interest in multiindex_set?(again)

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2003-07-14 14:12:32

Daryle Walker ha escrito:

> On Saturday, July 12, 2003, at 9:21 PM, Joaquín M López Muñoz wrote:
>
> > Hi again,
> >
> > ----- Mensaje Original -----
> > De: Fernando Cacciola <fcacciola_at_[hidden]>
> > Fecha: Sábado, Julio 12, 2003 7:32 pm
> > Asunto: [boost] Re: Re: Interest in multiindex_set?(again)
> >
> > [stuff about conceptual structure of multtindex_set deleted]
> >
> > OK, I'm glad we finally got to understand each other :) There's a
> > problem with the name of the class. Others have expressed dislike for
> > "multtindex_set". Alternative candidates are "indexed_set" and
> > "indexed_table". I haven't decided yet for one, plus there's the
> > problem of which namespace should this live in (regardless of whether
> > it is promoted to namespace boost later). The alternatives so far are
> > (name of the class/associated namespace)
> >
> > * multiindex_set/boost::multiindex
> > * indexed_set/??
> > * indexed_table/??
> > * ??/boost::container (proposed by Daryle)
> >
> > boost::container I don't like because some of the associated small
> > utility classes and functions (less_by, get, project) shouldn't really
> > belong into a general-purpose namespace like container which is
> > supposed to hold other contributions. Also, there's the additional
> > problem that the class and the namespace shouldn't be named the same
> > (it makes some compilers choke, this has been discussed in connection
> > with Boost.Tuple). Suggestions in this area are most welcome.
> [TRUNCATE]
>
> If the small utility classes are sufficiently independent from your
> main classes, then put them in separate (possibly unrelated)
> namespaces.  I don't we've ever reviewed a multi-domain package,
> though.  Or we can review the utility parts separately, first.
>
> Daryle

Well, to sum it up, these are the public names of the library:

0 multiindex_set (haven't decided on the final name, still doubting
between indexed_set and indexed_table).
1 swap, equality and comparison operators
2 index_type
3 get (function to retrieve refs to an index of a given multiindex_set)
4 iterator_type
5 const_iterator_type
6 project (function to convert between different indices's iterators)
7 index_list (a type list for specifying the indices composing a multiindex_set)
8 unique and non_unique (index traits classes that go into the index_list)

get() and project() are sufficiently well specified that they won't clash with
similar overloads belonging to namespace boost. But the rest of names,
which are classes instead of functions, are problematic: their names are too
general to be safely put into namespace boost without risk of collision.
So I guess some namespace have to be set up for them.
Besides, there's the problem of the yet to be written member<> utility (that
you're already familiar with). This clearly is a very general utility that has no
particular ties to multiindex_set, so I don't know where it should go.

So the two problems are:

* Where to put 2,4,5,7, and 8? For known reasons, boost::multiindex_set
is not a good candidate (problems with having a class and a namespace named
the same).
* Where to put member<>?

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

>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost