Re: [boost] string_algo Formal Review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-22 12:50:09

On Wed, Oct 22, 2003 at 09:17:20AM -0400, Beman Dawes wrote:

[snip]

> >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.
>

So what it your suggestion for the library organization?

I will give you an example. boost::string_algo::trim() function performes trimming.
(i.e. it removes spaces from the start and end of a sequence). 
Because there could be a need to remove something else then the ordinary space (0x20),
this algorithm, takes a predicate as an argument that used to identify,
if a paericular character should be removed.

boost::trim() does exactly the same, with only one difference. It works with ordinary
definition of space. Therefore it needs a "locale", to correctly classify a space.

The second version is obviously only a shorthand for the first one, but it is most
widely used and it would not be good to require from the user, to always used syntax like this:

trim( str, is_space<char>() );

This example shows the reson for the separation. 

So to make the task easier, plase consider this example and try to suggest a way how
these two functions should be organized.

And BTW, both variants have the same number of arguments.
 
> >- 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?
> 

Please consider the example above. In my opinion, this organization is natural.
Generic, harder to use variant is hidden in the lower namespace layer, yet
it performes the same function as the more specific one. So why would they
have different names?

Regards,

Pavol