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

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2005-02-17 15:10:45

----- Mensaje original -----
De: Thorsten Ottosen <nesotto_at_[hidden]>
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