Re: [boost] namespace organization (was Poisoning Koenig lookup)

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2002-10-29 11:33:52

Peter Dimov wrote:
> > I understood that the idea of Koenig lookup
> > was to allow me to use those kinds of short names without having to say
> > myprefix_shortname(iterator) every time.
> 
> No, the idea of Koenig lookup is to let unqualified calls work. It doesn't
> allow shorter names.

But one of the points of namespaces is so that I can use shorter 
(though still descriptive, in context) names without causing clashes. 
Koenig lookup was to help make namespaces work better to encapsulate 
interfaces. Seems to me they ought to work together. If we can't make 
it work, okay, but it seems to me we can.

> When you introduce a function 'type' that is intended to take advantage of
> ADL, you are effectively claiming ownership on the name 'type' in all
> reachable namespaces. 

Yes, this is so. The question is, what should the set of reachable 
namespaces be? Do we really want deriving from boost::noncopyable to 
pull in the whole of boost's interface? That's really what I'm arguing 
against in the end.

> You could argue that those reachable namespaces should
> change to not include 'type', but the typical approach is to fix the problem
> on your end.

So you're suggesting that because someone derives from one of these 
boost utility classes, we've now effectively put the entire boost 
namespace off-limits for use by arg-dependent lookup in the boost 
user's namespaces? Because if I'm claiming ownership of the name for 
that use in my namespace, so equally is boost implicitly claiming 
ownership of that name for arg-dependent lookup -- its use, even though 
not intended to be arg-dependent, prevents anyone else's.

Since these boost classes are _intended_ to be derived from, this seems 
wrong to me. And it's not that hard to backwards-compatibly fix on 
boost's end, by moving the base classes down into included 
sub-namespaces which encapsulate those classes' intended interfaces. 
Moreso since library code IMHO should be more careful about 
unnecessarily imposing restrictions on user code.

George Heintzelman
georgeh_at_[hidden]