Re: [boost] string_algo Formal Review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-10-22 08:17:20

At 03:33 AM 10/22/2003, Pavol Droba wrote:

 >On Tue, Oct 21, 2003 at 11:12:34PM -0700, Jeff Garland wrote:

 >> Now for a few new issues:
 >> 1) Any reason why we can't put all functions in namespace
 >boost::string_algo
 >> (or boost::algorithm::string)?  I found it a little tricky to figure 
out
 >which
 >> things were boost versus string_algo.
 >
 >There are more resons for separation of functions in different 
namespaces.
 >
 >- First is a logical decomposition.
 >  Ordinary user should be able to find all functionality
 >  in the namespace boost. The selection of algorithms in this layer was
 >  designed to cover most of common needs.
 >  string_algo namespace, on the other hand, contains more generic 
variants,
 >  mostly targeted for advanced user who want to experiment and gain more
 >  power from the lib.

The problem with guessing about which kind of user will want to use which 
functions is that users often don't fit into neat categories. A single user 
may well want to use a function or two from each of the namespaces. With 
multiple namespaces, that gets messy from the user's viewpoint. Please 
don't forget the requests you've already gotten to move some or all of the 
namespace detail functions out into one of the user accessible namespaces.

It would seem a lot less messy just to put all the algorithms in namespace 
boost::algorithm::string as Jeff suggests.

 >- Second resons is syntactical. If all functions would be in one 
namespace,
 >  there is a big probablility of name clashes. Because the majority of
 >  arguments in the algorithms is templated, the only distintion between
 >  different variants of the same algorithm is the number of paramters.
 >  So putting everything into one namespace would most probably imply the
 >  need to rename some functions.

That's probably a sign that some functions need renaming anyhow. Think 
about it - if there is so little difference between two functions in the 
same namespace that overload resolution can't tell them apart, is moving 
one of them into a sub-namespace really a good idea? Sure, overload 
resolution now works, but how is the poor programmer expected to keep the 
difference straight?

--Beman