[boost] Re: Re: algorithms namespace

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-02-18 17:07:02

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.