Re: [boost] Re: Re: Re: Re: algorithms namespace

From: Pavol Droba (droba_at_[hidden])
Date: 2004-02-19 12:01:53

On Thu, Feb 19, 2004 at 10:37:19AM -0500, Edward Diener wrote:

[snip]

> > I'm with Pavol here. One useful guideline is: "Do not overload a
> > function if you care which overload would be called." In other words,
> > functions with the same name should - roughly - have the same effect.
> > They may differ in efficiency, const correctness, and so on, but the
> > general effect should be the same.
> >
> > In other words, if I write replace(s, x, y), it should always replace
> > all occurences of x in s with y and return the result (for example),
> > no matter whether it's std::replace, str::replace, or cnt::replace.
> >
> > This is a guideline, not a rule. You can break it if you think the end
> > result would be better without it. But if followed, it leads to code
> > that is more readable and less error-prone.
> 
> This was very much the point that I was making also. If one overloads too
> many functions with the same name in a single namespace, I believe it
> becomes confusing for the end user unless all of them are closely related to
> the same objects. That is why I was in favor of sectioning off boost string
> and boost container functions in their own boost::algorithm namespaces.
> 
> As far as typing in long namespace names, aliases can alway be used.
> 
> Finally I believe very strongly in sectioning off code into its own
> namespace. It creates much less headaches at the expense of possibly more
> typing, but this is a tradeoff I will always take. I believe it leads to
> much clearer code.
> 

You are arguing with a generic ideas. Well, there's nothing bad about them.
There are few problems however.

Every good idea turns bad if it gets missused. Sectioning is fine, until your
reach a level when it takes more then it brings. 

Boost is already partitioned into several namespaces. Usualy there are 2 levels:
"boost" and "boost::library_name".
Now we are trying to add another level. IMHO it is starting to be too much.

First of all, what would such a paritioning bring? I think, that the ambiguity problem
is not a problem in the case of algorithms (it has been explained before).

Current proposal tries to split namespace by the libraries. This partitioning is 
artificial and not related to any algorithms categories. For instance, many 
algorithms in the string algo library can be categorized as container algoritms 
(they work with containers) and vice versa. It is not sufficiently possible 
to draw a border line between these two, and what will happen if more algorithms 
will be added?

I think, that such a hierarchy is useless, so there is not a good reason to use it.
It might be possible to create some other hierarchy, but i doubt, that it
will be any better.

Regards,

Pavol