C++, Go and proton API layout.

[aconway <ac...@redhat.com>]

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org