if (c++ && x++)

[Ravi Pandya <ravi>]

After thinking about it, I can see a couple of problems with having
the low road delve into the depths of BNF protocol grammars and the
like. For one, this means that our developers need to learn an
enormous amount. They must be able to meaningfully interpret this
grammar before they can get anything out of the backend that they can
use. (This still applies if we give them access to transceivers that
package up the syntax; they still have to interpret the semantics.)
Second, I don't think C is the right language to interpret this
protocol. We have an elegant encoding and decoding scheme that makes
intimate use of object-oriented concepts. It would be much harder to
do in C.

I've always envisioned the C interface being at the docs & links
level, with high-level procedures for manipulating the back end data
objects and shoving data in and out of them. The C routines would do
little more than data translation, member function invocation, and
exception handling.  A C user could get back pointers to X++/FEBE
objects, but they would be blind; they are only useful for passing
back to another one of our routines. (We would need to pay some
attention to garbage collecting pointers that get sent out into the
world; the simplest solution is to keep strong pointers for them in a
table somewhere and wait for the user to explicitly delete them.)

Since this is a high level approach, we'd have to be careful to design
the library interface so that we don't have to package the entire X++
library as a set of C routines. This will call for some ruthless
editing when the time comes. I don't deny the necessity, but I'm not
looking forward to it.
	--ravi


P.S.	The way my part Scottish mother used to sing the song:

	"Ye take the high road, and I'll take the low road,
	and I'll be to Scotland before ye."

	D'ye ken she has the right of it?