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 <[EMAIL PROTECTED]> > > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
