Re: [boost] Re: Re: algorithms namespace

From: Pavol Droba (droba_at_[hidden])
Date: 2004-02-19 02:45:46

On Wed, Feb 18, 2004 at 05:07:02PM -0500, Edward Diener wrote:
> Douglas Paul Gregor wrote:
> > On Wed, 18 Feb 2004, Pavol Droba wrote:
> >> If there would be just one boost::algorithm and everything inside
> >> it, than aliasing would work just fine. But imagine having
> >>
> >> namespace algo=boost::algorithm;
> >> namespace sa=boost::algorithm::string;
> >> namespace ca=boost::algorithm::container;
> >>
> >> It is easy to get lost in such a lot of namespace. One would have to
> >> look into the docs to see which algoritm lies in which namespace. It
> >> could realy be painful.
> >
> > I think the subnamespaces are a bad idea. I suggest that
> >
> > #include <boost/algorithm/string.hpp>
> >   - Includes all string algorithms, in namespace boost::algorithm
> >
> > #include <boost/algorithm/container.hpp>
> >   - Includes all container algorithms, in namespace boost::algorithm
> >
> > #include <boost/algorithm.hpp>
> >   - Includes all boost/algorithm/* and imports them all into namespace
> > "boost" with using declarations.
> 
> I am concerned about the name of an algorithm in the generalized
> boost::algorithm namespace not reflecting the fact that the algorithm refers
> to strings or containers. Of course I am aware that overloading will allow
> different algorithms which have the same name to refer to different objects,
> but still a fairly generalized name may not create a specific enough
> mnemonic for me, as an end-user, to be comfortable enough with, to know that
> the algorithm refers to string(s) or container(s). OTOH having the algorithm
> in the boost::algorithm::string or boost::algorithm::container namespace
> tells me that the algorithm is string-centric or container-centric, and then
> the generalized name for the algorithm bothers me less because I will always
> be invoking it by specifying the full namespace ( or namespace alias ) name.
> This is purely an aesthetic reaction, and the fact that I like generalized
> names for free-standing functions ( and function templates ) which reflect
> the action but specific namespaces which tell me to what the action might
> refer, more than I like generalized names in the same namespace referring to
> very different objects and actions upon them.
> 

Actualy I don't realy think, that ambiguity is a big issue here. For instance,
string algorithm library is not based on a specific string implementation,
rather it works on any container with a reasonable properties. I expect the
same from other parts of the algorithm library. 

An algorithm is an algorithm, it does not mather if it works on a string or 
on something else from the user perspective. So overloading is a natural way 
to solve the problem.

Please give me an example of an algorithm, that can be threated differently
for strings and for containers. If there would be something like that (I don't
see any), than is would make sense to use different names, rather then just
different namespace. Otherwise, a user can get quite confused.

Just imagine, two functions with the same name, with the same arguments,
both doing the different thing and the only difference is a namespace. It is not a 
good practice.

So to conclude, I think, that putting everything into namespace algorithm
is probably the best ide. And I'd like to support also the idea of
importing all relevant names into "boost" namespace.

Regards,

Pavol