Namespaces, Again

Today I made a change to the way namespaces in POCO are handled. First, I got rid of the unpopular namespace macros. Second, I introduced an outer Poco namespace.
The change was quite painless and with the help of Visual Studio’s Replace in Files function I was able do the complete change in about two hours (including building and running the testsuites).

For the namespace syntax, I chose same style as in Boost. This means that namespace blocks are not indented, and the way the braces are placed is different than the way the Coding Styleguide suggests. Instead of Foundation_BEGIN and Foundation_END we now have

namespace Poco {
namespace XML {

class ...
{
};

} } // namespace Poco::XML


This seems like a good compromise between readability and style.
Unless there are major objections, I plan to put the changes into 1.2. I will probably also add some kind of backwards compatibility switch in the form of a using namespace Poco; in Foundation/Foundation.h if a certain preprocessor macro (POCO_USE_POCO_NAMESPACE) is defined.

Update:
I am thinking about getting rid of the Foundation namespace alltogether. So, everything in the Foundation library will be directly in the Poco namespace, while the other library will use two namespaces (Poco::XML, Poco::Util, Poco::Net). I think this makes sense, because Foundation is the “heart” of Poco, and all other libraries depend on it. Boost does it similar. Also, shorter namespaces make the code more readable (Poco::Foundation::BufferedBidirectionalStreamBuf really is quite long).
Also, I am thinking about changing the directory hierarchy for header files, by introducing a Poco top-level directory. This will again sync namespaces to include file hierarchies, so we have
#include “Poco/BinaryWriter.h” for Poco::BinaryWriter
and
#include “Poco/Net/HTTPClientSession.h” for Poco::Net::HTTPClientSession.

The only downside is that this will break existing code and require a global search/replace session. However, my own experience with our quite expensive codebase shows that this can be done quite easily. I really want to put this into 1.2, because the longer we wait with breaking changes, the more damage will result.