Re: [boost] Re: [indirect container] RFC on naming of libraryandclasses

----- Mensaje original ----- De: Thorsten Ottosen <nesotto@cs.auc.dk> Fecha: Jueves, Febrero 17, 2005 8:12 pm Asunto: [boost] Re: [indirect container] RFC on naming of library andclasses [...]
| If indirection is not really the unifying theme, perhaps you should use the name | Boost.ManagedContainer, which I think was suggested at some point. | ('ManagingContainer' might be more correct, but doesn't sound good.)
Managed container is a good name. To recap, I think these are good condidates: Boost. Managed Container Boost. Managed Pointer Container Boost. Pointer Container Boost. Clonable Container Boost. Clonable Pointer Container Boost. Cloned Container
My personal favourite would be Boost.Cloned Container with class names like this:
cloned_vector<T> cloned_map<Key,T>
When I think about it, I see cloning as the most central concept; in fact, the only new policy of the containers is the CloneAllocator.
IMHO, "cloned/clonable container" hardly suggests what the lib is about: a clonable object has a rather well defined meaning, and so a clonable container seems to mean a container with some sort of clone() memfun. "Clonable objects container" (better than "clonable pointer container") is 100% accurate, but too verbose. A possibility without ambiguities is "clone container", i.e. a container of clones. As for the "managed" line, I think it resonates with some issues none of which has to do with the subject at hand: * "managed" as bounds checked. * "managed" as belonging to the world of C++/CLI (ugh!) So, if we rule out "indirect" for the reasons you explained, we're left with "pointer container". I think this is good: * std::set is a value container (elements have value semantics), so it is natural to extend the idea to ptr_set being a pointer container. * The term has some tradition. * It doesn't sugest anything different to what the lib is about. Actually ptr_containers do more than just holding pointers, but well. * When you augment the lib to support shared_ptrs, the name still holds. To sum it up, I vote for "pointer container", "clone container" being my close-second choice. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

JOAQUIN LOPEZ MU?Z wrote:
----- Mensaje original ----- De: Thorsten Ottosen <nesotto@cs.auc.dk> Fecha: Jueves, Febrero 17, 2005 8:12 pm Asunto: [boost] Re: [indirect container] RFC on naming of library andclasses
[...]
If indirection is not really the unifying theme, perhaps you should use the name Boost.ManagedContainer, which I think was suggested at some point. ('ManagingContainer' might be more correct, but doesn't sound good.)
Managed container is a good name. To recap, I think these are good condidates: Boost. Managed Container Boost. Managed Pointer Container Boost. Pointer Container Boost. Clonable Container Boost. Clonable Pointer Container Boost. Cloned Container
My personal favourite would be Boost.Cloned Container with class names like this:
cloned_vector<T> cloned_map<Key,T>
I dislike the names involving clonability. Isn't it true that in many ordinary uses of the library there will be no cloning?
As for the "managed" line, I think it resonates with some issues none of which has to do with the subject at hand: * "managed" as bounds checked. * "managed" as belonging to the world of C++/CLI (ugh!)
We don't have to avoid every term Microsoft (or some other vendor) has uzed as a buzzword, do we?
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Jonathan

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cv2v7j$dg7 | I dislike the names involving clonability. Isn't it true that in many ordinary | uses of the library there will be no cloning? yes, true. -Thorsten

On Thu, Feb 17, 2005 at 09:10:45PM +0100, JOAQUIN LOPEZ MU?Z wrote:
IMHO, "cloned/clonable container" hardly suggests what the lib is about: a clonable object has a rather well defined meaning, and so a clonable container seems to mean a container with some sort of clone() memfun. "Clonable objects container" (better than "clonable pointer container") is 100% accurate, but too verbose. A possibility without ambiguities is "clone container", i.e. a container of clones.
As for the "managed" line, I think it resonates with some issues none of which has to do with the subject at hand: * "managed" as bounds checked. * "managed" as belonging to the world of C++/CLI (ugh!)
So, if we rule out "indirect" for the reasons you explained, we're left with "pointer container". I think this is good: * std::set is a value container (elements have value semantics), so it is natural to extend the idea to ptr_set being a pointer container. * The term has some tradition. * It doesn't sugest anything different to what the lib is about. Actually ptr_containers do more than just holding pointers, but well. * When you augment the lib to support shared_ptrs, the name still holds.
To sum it up, I vote for "pointer container", "clone container" being my close-second choice.
As a short remark, I second this opinion with the strong preference over "pointer container". The library combines serveral aspects, but the "pointer" is actualy the only unifying entity in all of them. Regards, Pavol

"Pavol Droba" <droba@topmail.sk> wrote in message news:20050217204616.GW3808@lenin.felcer.sk... | On Thu, Feb 17, 2005 at 09:10:45PM +0100, JOAQUIN LOPEZ MU?Z wrote: | > To sum it up, I vote for "pointer container", "clone container" | > being my close-second choice. | > | | As a short remark, I second this opinion with the strong preference | over "pointer container". | | The library combines serveral aspects, but the "pointer" is actualy | the only unifying entity in all of them. Allriiighty then, we have a winner :-) Thanks for your input. -Thorsten
participants (4)
-
JOAQUIN LOPEZ MU?Z
-
Jonathan Turkanis
-
Pavol Droba
-
Thorsten Ottosen