[boost] IndexedSet Review: unified proposal for naming

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-03-30 12:09:41

I don't think any more people will join the review, so
I've collected all the contributions regarding naming issues
and tried to come up with a "unified" naming scheme.
As it was expected, suggestions vary wildly, and the
choicespan is growing as the review advances, so maybe
this is a good time to try to reach a compromise.
Please note everybody will have a favorite alternative,
but the idea is that this proposal at least satisfies everybody
and is abhorred by nobody. I'd appreciate if you take a
look at the proposal and either accept it or provide
strong argument against it (or against parts of it). It would
help if further discussions conform more or less to the structure
of this proposal, so as to ease gathering results later.

Also, I'm not the review manager and it is not for me to make
the final decision on this and other issues, but I think some
preprocessing work could be beneficial.

So:

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

CONTAINER NAME
Proposal: composite_container.
Rationale: It more or less suggests what it is. "index" does not
appear in the name, but to compensate it'll show anywhere
else (the namespace and the parameters like index_list) so
the index concept is ubiquitous. It does not use "set" as
composite_container in general is not a set. It matches
the concept it'll model in the future (when this section
is written.)
Alternatives proposed by reviewers: indexed_set,
multicontainer, indexed_table, table, indexed, composite_set,
set (distinguised from std::set by the namespace).

LIFTING TO NAMESPACE BOOST
* Proposal: container lifted only one level:
boost::container::composite_container
* Rationale: Lifting to boost seems too long
a jump, and lifting to both places is overkill.

LIBRARY NAME
* Proposal: Boost Multi-index Container Library
* Proposal for short form: BMCL
* Rationale: The name is descriptive enough, and gives room
for future containers to be added here (indexed maps, the
infamous bimap, etc.)

REGULAR INDICES
* Proposal: Name changed to "ordered indices".
* Rationale: The name is far more descriptive. When
first met, "regular" means nothing. Allows for a nice
solution to the clash with std::unique (see below).

INDEX NAMES
* Proposal: "unique" and "non_unique" changed to
"ordered_unique" and "ordered_non_unique".
* Rationale: No one opposed and some liked
it. Solves the clashing with std::unique. Extends nicely
to hashed indices (unordered_unique etc.) It is more
descriptive. In favor: Gary, Dave. Rob dislikes
the unique/non_unique suffix, but alternatives do not
look better IMHO.

NTH_INDEX_TYPE AND FAMILIY
* Proposal:

nth_index<N>::type
index<Tag>::type
nth_index_iterator<N>::type
nth_index_const_iterator<N>::type
index_iterator<Tag>::type
index_const_iterator<Tag>::type

* Rationale: It eliminates the dreaded "_type" suffix. It does not clash

with inherited "iterator" and "const_iterator" types. Two reviewers
loved it (Darren, Dave), the rest said nothing about it.

UPDATE MEMFUN
* Proposal: Change to "replace".
* Rationale: It more faithfully describes the semantics of the
operation. One reviewer in favor (Dave), plus Pavel and
myself.

HEADER ORGANIZATION
* Proposal: follow a fine-grained policy, possibly with
"grouping" headers (e.g. for key extractors.)
* Rationale: Seems like good style. Two reviewers favored
this approach (Dave, Gary). The rest didn't care/say anything.

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