From: Ed Brey (edbrey_at_[hidden])
Date: 2001-10-26 07:38:06
From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> This is actually a particular case of a more general problem with name
> encapsulation: the politic of owning a namespace prohibiting anyone to add
> names in it isn't always a good design. Some frameworks are extensible by
> nature, and a closed namespace isn't the right place to put it.
> IMO, it might be better to lay out a criteria for adding new names and
> resolving the possible conflicts. In the case of constants, because of their
> inherent fixed nature, this scheme is unlikely to lead to inconsistent
> program behaviour.
The concept of an open framework is certainly a valid one. It introduces a tradeoff. On the plus side, it allows access through a single interface for predefined plus users items. On the negative side, it means that code that worked one day may suddenly stop working, just because a library was upgraded, even if that library has been careful to maintain backward compatibility.
The value of the former is quite limited, since the alternative is to have two parallel interfaces, i.e. the boost namespace and the user's namespace. Using two different namespaces seems quite reasonable. Plus in regions of code where many names are used from each, the using directive can be applied and the namespace issues go away. This reintroduces the chance of a name conflict, but notice that the extent of the damage (i.e. resulting code changes) is limited to a given region of code, rather than being global.
Unless there is some substantial benefit that can be shown to having a single merged interface, my opinion is that the robustness of separate namespaces is much more valuable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk