[boost] Re: Formal Review: Indexed Set (Naming issues)

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2004-03-26 14:15:02

>
Powell, Gary <powellg <at> amazon.com> writes:

Reply to the 2nd part of your post, here I go.

> Namespace:
>   I like boost::container::multi_indexed_sets But I could live without 
the "::container".
> 

multi_indexed_sets? did you mean indexed_sets or is this
a new proposal for the namespace name?

> I'm not crazy about lifting the namespace into boost. I foresee that boost is 
going to get cluttered so some
> organization early will help.
> 

As I say in the review notes, I'll do whatever people
agree on. My only concern with having the namespace
as a sub of boost::container is that ids that long as
boost::container::multi_index will favor using directives or
namespace aliases. Anyway.

>   "mix" hits my pun loving funny bone, hence it shouldn't be used! 
Besides "mix_in" has a different meaning
> and will confuse people. I don't have to type the name of the container very 
often in comparison to
> everything else so a clear name is worth a few extra characters.
> 

Yeah, I think you're right. mix dropped (seemed like
I was the only one that liked it). We are left then
with indexed_set, multicontainer, multi_container.

> Regular indices:
>   I like "ordered indices" as it says what they are. I hate writing 
documentation when readinghte code
> explains everything clearly.
> 
> Index names:
>   ordered_unique ordered_non_unique
>   They say what they do. Always good for self docuementing code.
> 
>   "set_like" sounds so 90's teenage talk... "whatever.."
> 

I like them too. Future hashed indices can be
called unordered_unique and unordered_non_unique, in
heavenly harmony with upcoming std hashed sets.

> Nth_index_type & family.
>   Yeah, I'd like to see the _type dropped. If you have to have a unique 
name, "_t" is ok, but still sucks.
> 

The only places where dropping "_type" causes problems
is iterator_type<> and const_iterator_type<>. But wait,
I think I have something that may please everybody:

template<int N> struct nth_index; 
template<typename Tag> struct index; 
template<int N> struct nth_index_iterator; 
template<int N> struct nth_index_const_iterator; 
template<typename Tag> struct index_iterator; 
template<typename Tag> struct index_const_iterator; 

Comments?

> Header Organization:
>   The only reason for omitting dependant headers is if they are 
not "dependent." I.e. that you need the sub
> header for accessing the container, but the primary header is all that is 
needed to declare the container.
> Otherwise include everything that is required. (IMO)

This seems to lead to a finer-grained separation. OK
with me, monolithic headers do not seem to be on vogue
at Boost.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo