Hi Arkadiy, Arkadiy Vertleyb ha escrito:

"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote

...

I'm really lost here, naming issues are so nasty. Looking fwd to knowing your ideas.

I think we have a rather generic situation here, which is the library has one main class. In which case it would be rather natural to have the class's name the same as the library name, and the same as namespace name.

Except that the class name would clash with the namespace.

There are a few other libraries in Boost that are like this, such as lexical_cast, threads, function, etc. Some don't have their own namespaces, and just live in "boost" (however, the question is what to do with the supporting classes? There might be quite a few of them, and one doesn't want to pollute the boost namespace with the library-specific things). Others add the suffix 's' to form the namespace name (like tuple and tuples).

I think at least one good name was found here, and this is "multi_index". I honestly think this name should be reserved for the class, and this class should be under "boost" (or promoted to boost). This is what you had before, when you had "indexed_set" and "indexed_sets". I kind of lost the track of why this kind of naming was rejected.

This is prmiarly my concern. indexed_set can no longer be regarded as a generalized *set* since sequenced (list-like) indices were brought in.

I think that in the situation like this, the library name and the namespace name should be just derived from the class name using one consistent scheme.

So what about accepting the Boost.Tuple scheme, and having "multi_index", "Boost.MultiIndex", and "multi_indexes" (or multi_indices)? I would still preffer "indexes", but native English speakers might not agree with me :)

This is just my personal opinion, but multi_index, not being a noun but rather an adjective, does not seems appropriate to name a container. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo