On Fri, 2015-09-11 at 07:24 -0400, Justin Ross wrote: > I wasn't subscribed before, so I'll have to address Alan's notes in a > new > thread. > > My reading of the internet suggests that "using namespace" is awfully > common. Is it really anathema?
It is common, and normal in .cpp files, exactly as in your example, and it works very nicely. It is useless in header files unless you intend to alias the definitions into a different namespace for everyone who includes that header file - in which case why didn't you just put them there in the first place? C++ templates, inline functions and now constant-expressiona encourage writing code (not just delcarations) in header files. The boost and std libraries are almost exclusively header files. In a large codebase with a mix of header and .cpp code it becomes a mental drag to remember whether you are in a context where you can say "boost::shared_ptr" or just "shared_ptr" so you end up just qualifying everything. So in short, deeply nested namespaces are possible in principle in C++ but a bad idea in practice. > Here's the upside of using namespaces: [snip] > The namespace handling in the examples remains reasonable, imo: > > - https://github.com/ssorj/stutter/blob/master/src/broker.cpp > - https://github.com/ssorj/stutter/blob/master/src/client.cpp > - https://github.com/ssorj/stutter/blob/master/src/helloworld.cpp Those are fine. You need to write some header files for a library based on proton to appreciate where the pain lies. namespace mynamespace { #include <proton/core/message.hpp> // Need messge_value decl. // Forward declare receiver, we only pass by reference namespace qpid{ namspace::proton { namespace:core { class receiver; }}} // Finally my function qpid::proton::core::message_value get_message(qpid::proton::core::receiver&) } The forward declaration is important, minimizing unnecessary #includes is key to keeping C++ build times manageable in a large code base. We can't use "using" in this header file without aliasing proton types directly into "mynamespace" for everyone who #includes the file, which defeats the purpose of having a separate namespace. > I'm not trying to say this is the layout we need to end up at. It > could > use some improvement. > > But having a plan, with understandable grouping, and positiioning by > user > priority, is to me a big win. It helps the API user to focus on the > most > important things first. The layout is logical and useful. I think it makes sense to organize documentation for all bindings like this, and it maps directly to java and python without unusual pain. However it does not map well in C, C++ or Go *programming* constructs. C and C++ do not do well with deeply nested namespaces. Go does not do well with generic package names like "core" or "types" that are meaningless out of context. Programmers in any of these languages will be suspicious of a "simple, ligthweight protocol library" that has to be split into 7 or 8 namespaces in order to be comprehensible. The entire C++ std or boost libraries go in a single namespace and nobody's head explodes - the documentation for those libraries *does* use a layout like you propose, but it is not imposed on the programmer coding time. Programmers will (hopefully) spend more time writing proton code than learning how to use proton so the coding overhead is important. Go is a fan of small but *self-contained* packages with very clear dependencies. My Go binding currently has 3 packages (all under the qpid.apache.org/proton prefix): amqp: AMQP types and conversions, independently useful if you want to encode/decode AMQP data, and a dependency for the other two packages. reactor: the proton core and reactive API, all you need to build event -driven AMQP applications. Depends on amqp. messaging: procedural, blocking AMQP messaging API, depends on AMQP. Internally implemented in terms of reactor but does not require the user to use reactor at all. Even in python and Java it is instructive to note *why* it is ok to impose the layout at programming time. Java programmers will never *use* the namespaces, their IDE's will automtically insert import statements and they will use unqualified class names. Python doesn't care what you import or alias where. The reactor module in python already imports the entire python module as a convenience, python programmers will import and alias at will and also never use the qualified names. So I think the layout is good, what we are missing are some guidelines for package naming in languages where deep trees and numerous namespaces are not the norm. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
