Re: [boost] Re: Re: [indexed_set] revised naming proposal

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-04-12 16:17:09

From: =?windows-1252?Q?JOAQUIN_LOPEZ_MU=3FZ?= <joaquin_at_[hidden]>
> De: Rob Stewart <stewart_at_[hidden]>
> 
> > > > Why not just "index::list?"
> > > 
> > > "list" seems too terse to me. It could lead the reader
> > > to think it is some sort of container (which is not). Take into
> > > account the namespace can be populated in the future
> > > with other containers derived from the main one.
> > 
> > I suppose in a given use case, a "using boost::index" (or "using
> > boost::multi_index") may be in force, so it would boil down to
> > just "list."
> > 
> > However, neither "index_list" nor "list" really says the right
> > thing.  How about turning it around: list_index?
> 
> I don't get how list_index is more meaningful than
> index_list. I mean, index_list is a list (a typelist,
> actually) of indices (index specifiers, actually).
> Would you care to ellaborate? (thanx!)

Chalk it up to a brain fart.  I was not paying enough attention.
Now that I am, what about changing it to "indexes" or "indices"
according to your preference?  IOW, I don't think "list" needs to
be part of the name at all.  That name works fine regardless of
whether it is elaborated.

> > > from my part here. There's still the pending issue of whether
> > > to move into boost::container.
> > 
> > I think the argument that "a" container library has to be the
> > first one is valid, but was there sufficient consensus that such
> > a namespace was warranted?  If there is consensus, your library
> > is a perfect candidate.  If there isn't, it would be painful to
> > put your library in the "container" namespace only to rip it out
> > later.  If you don't do it and folks agree it is worthwhile, then
> > yours would be just one more library to move into the namespace
> > at that time.
> 
> Well, it's all about not wasting effort. Hopefully, some
> other boosters (and the authors of container libraries
> in Boost) will jump in and express themselves for a

That will be ideal.  I wasn't paying attention, but has this been
addressed in a separate thread with an appropriate subject in
order to garner their involvement?

> On a more philosophical level, I don't quite like
> the idea of 1st level namespaces per se. IMHO, these are
> the most plausible justifications for this kind of
> namespaces:
> 
> 1. Help avoid pollution of boost namespace.
> 2. Group libraries semantically affine.
> 3. Group libraries that will be likely used
> in cooperation in many programs.
> 
> As for 1, I don't see any danger of namespace
> pollution in Boost since libraries are accepted one by
> one and these things are carefully checked before.

Reasonable, but it puts the onus on each new library to avoid its
predecessors.

> As for 3, I don't really think that a program
> using an indexed_set will get a greater chance of
> using also multi_array, for instance (on the

Agreed.

> 2 is an aesthetical issue. I don't see any
> practical benefit from having this kind of grouping.
> One does not discover new libraries by way of
> exploring the "sourrounding" namespaces, so to say.
> If anything, the categorized lib index in Boost serves
> this purpose well.

You're partially correct.  First, grouping related libraries
under a single namespace means that it is a well known namespace
with many things beneath its wings and yet it doesn't pollute the
main namespace with all of those names.  IOW, it carves out a
large chunk of names and separates them and it relates those
names.  Is it necessary to separate them?  Perhaps not now, but
it probably neatly resolves tensions other library authors have
felt in the past.  Does grouping the names serve a purpose?
Sure.  If you're looking for something related to containers, the
"containers" namespace seems a likely place to look.  It's a
discriminator that effects a binary search.  It can even help
with the library index to which you referred because, as the list
grows longer, it becomes increasingly difficult to find the
library you want.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;