IndexedSet Review: unified proposal for naming
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
Hi, On Tue, Mar 30, 2004 at 07:09:41PM +0200, Joaqu?n M? L?pez Mu?oz wrote:
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
I have just one remark about the namespace usage. IMHO it is an overkill to provide a special namespace for every container. I think, that putting this all containers into boost::container namespace is verbose enough. There has been very similar discussion about the algorithm namespace (namely the string algorithm library). Current situation is that everything resides in boost::algorithm namespace and interface names are lifted to boost namespace. This model has been settled as a reasonable compromise. It is worth to mention, that there are generaty more free stading names in algorithm libraries than in the container ones. So if the name-clashing problem is not here, I don't see it in container case. Last argument in favor of proposal I have mentioned is to have one uniform setup in the boost if possible. If the algorithm part is already settled, containers should follow. Regards, Pavol
Pavol Droba <droba <at> topmail.sk> writes:
NAMESPACE * Proposal: boost::container::multi_index
[...]
I have just one remark about the namespace usage. IMHO it is an overkill to provide a special namespace for every container. I think, that putting this all containers into boost::container namespace is verbose enough.
There has been very similar discussion about the algorithm namespace (namely the string algorithm library). Current situation is that everything resides in boost::algorithm namespace and interface names are lifted to boost namespace. This model has been settled as a reasonable compromise.
It is worth to mention, that there are generaty more free stading names in algorithm libraries than in the container ones. So if the name-clashing problem is not here, I don't see it in container case.
[...] I think indexed_set (or composite_container) cannot live without a namespace ot its own. There are many utility classes around the container with names like (to pick a few) * tag * index * member * identity These are *public* classes. Would you choose to have them in boost::container? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Tue, Mar 30, 2004 at 09:12:19PM +0000, Joaquin M Lopez Munoz wrote:
Pavol Droba <droba <at> topmail.sk> writes:
NAMESPACE * Proposal: boost::container::multi_index
[...]
I have just one remark about the namespace usage. IMHO it is an overkill to provide a special namespace for every container. I think, that putting this all containers into boost::container namespace is verbose enough.
There has been very similar discussion about the algorithm namespace (namely the string algorithm library). Current situation is that everything resides in boost::algorithm namespace and interface names are lifted to boost namespace. This model has been settled as a reasonable compromise.
It is worth to mention, that there are generaty more free stading names in algorithm libraries than in the container ones. So if the name-clashing problem is not here, I don't see it in container case.
[...]
I think indexed_set (or composite_container) cannot live without a namespace ot its own. There are many utility classes around the container with names like (to pick a few)
* tag * index * member * identity
These are *public* classes. Would you choose to have them in boost::container?
Ok, I see your point now. Still, I would prefer shallower namespace hierarchy if possible. Maybe renaming ig these *public* classes whould help. Or just putting these utilities in an extra namespace, keeping the main container class well accessible. Well, these are just crazy my ideas, but anyway, the issue is important enough to be worth of some discussion. Regards, Pavol
Joaquín Mª López Muñoz <joaquin <at> tid.es> writes:
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.
I don't know that there is a significant chance of a clash between the two 'unique's, since it seems they will be used in different contexts. The std::unique will be used in procedural body code, while the boost::container::unique will be used in the (complex) declaration of types. I think it would be a rare situtation to have 'using std;' statement in the same context where a type was being declared with a 'using boost::container;' statement in force... Also, disambiguation with 'std::' is both concise and familiar. Is the symmetry between 'ordered_unique' and 'unordered_unique' worth expanding the length of the former for? Matt
participants (5)
-
Joaquin M Lopez Munoz -
Joaquín Mª López Muñoz
-
Matthew Vogt -
Pavel Vozenilek -
Pavol Droba