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

From: Pavol Droba (droba_at_[hidden])
Date: 2005-02-17 15:46:16

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