I have been reminded that we actually had a discussion and put together an API layout proposal for proton APIs, and the C++ binding does not conform (nor does the coming-soon Go binding)
https://cwiki.apache.org/confluence/display/qpid/Proton+API+layout+prop osal I probably agreed to this at the time but now I've been involved in 2 new language bindings (Go and C++) as well as using some old ones (Java, python) I agree on the value of consistency and having a plan, but I am now concerned that there may not be a *detailed* plain that is good across all languages, and that forcing a detailed "general purpose" plan on all languages will end up being ugly in many/most languages. Go has severely blunted my tolerance for repetitive waffle in naming schemes. I don't have a solution here, I'll just try to pose the problem: For this discussion I am talking *only* about public API: public headers, packages, what have you. The detailed organization of implementation source is a separate question entirely. Lets consider python, C++ java and Go (oh and C!) In python you nest anything you want in anything else you want, as deep as you want, as fine-grained as you want, then import whatever you need wherever else you need it for ease of use. Don't think, Code!!! That's actually a good thing about python, but it doesn't foster the discipline that is a good thing about other languages. C++ has arbitrary nesting of namespaces with crappy, half-baked support. Yes, you can say "using" in a .cpp file but you *absolutely cannot* say it in a header file because that ties everyone who #includes the header to your choices. C++ compilers are HORRIBLY slow so minimizing references between header files is critical. To make matters worse C++ is increasingly written in header files. So you WILL have to type qpid::proton::reactor::reactor. Go-heads call this "stutter". It's ugly and tedious. There is stutter on two levels here: first 'qpid' and 'proton' are both just telling me I'm using AMQP support from the qpid project. Next putting a type called "reactor" (and almost nothing else) in a namespace called "reactor" is just, well, stutter. That is why standard C++ just has just *one* namespace "std::" and boost (while it uses lots of namespaces internally) puts almost every public class directly in the boost:: namespace. Java namespaces are crappy in their own way, made tolerable only by IDEs that automatically stuff the dozens of import statements you need for even the simplest task into your source code for you. Go has packages. When you import them, they can have DNS-based prefixes and arbitrary hierarchies BUT at the end of the day the *unqualified* package name is going to be used every time you refer to the package in your code. You can alias it of course, but it is good policy for the *unqualified* package name to be short and descriptive *by itself*. So e.g. "types", "util" or "extras" are terrible package names. Lets not forget C!! Proton C has one "namespace", `pn_` everything goes in there *directly*. It is not pn_proton_reactor_reactor, it's just pn_reactor. So I contend that while the layout plan is a useful organizing document and guideline, and it may be useful to translate it directly for some languages (python and Java), it is not a good fit for many languages (C, C++, Go) where multiple, deeply-nested name spaces are frowned on, especially in a "lightweight messaging library". Cheers, Alan.
