Re: [boost] Re: [indexed_set] revised naming proposal
Hi Jeff, ----- Mensaje original ----- De: Jeff Garland <jeff@crystalclearsoftware.com> Fecha: Domingo, Abril 11, 2004 8:31 pm Asunto: Re: [boost] Re: [indexed_set] revised naming proposal
On Sun, 11 Apr 2004 19:38:29 +0200, JOAQUIN LOPEZ MU?Z wrote
I'm good with everything in the proposal, except I think the library should still be called multi-index containers. I think if you leave that out people are likely to miss the fact that the library provides replacement containers.
You've got a valid point here. But I cannot turn your suggestion into a reasonably short name in the spirit of Boost.MultiIndex. Boost Multi-index Containers Library? This is too long to be scattered through the docs the way Boost.IndexedSet appears now. Shortened for easier reference to BMCL or BMICL? Maybe we should retain Boost.MultiIndex and use the fuller "Boost Multi-index Containers Library" at the header and preliminary paragraphs? I'm really lost here, naming issues are so nasty. Looking fwd to knowing your ideas. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"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. 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 :) Regards, Arkadiy
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
From: =?iso-8859-1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?= <joaquin@tid.es>
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.
"multi_index" could be used as an adjective, but I read it as a noun in the discussions. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
On Sun, 11 Apr 2004 21:26:05 +0200, JOAQUIN LOPEZ MU?Z wrote
You've got a valid point here. But I cannot turn your suggestion into a reasonably short name in the spirit of Boost.MultiIndex. Boost Multi-index Containers Library? This is too long to be scattered through the docs the way Boost.IndexedSet appears now. Shortened for easier reference to BMCL or BMICL? Maybe we should retain Boost.MultiIndex and use the fuller "Boost Multi-index Containers Library" at the header and preliminary paragraphs?
I don't have any problem with shorter names in the docs themselves. What I'm thinking is if I'm scanning the alphabetical library list for containers I might scan right by multi_array, multi_index,... But I think multi_index containers would catch my eye. Jeff
participants (1)
-
Arkadiy Vertleyb -
Jeff Garland -
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Rob Stewart