Jim,

J> There are probably other strategies worth exploring. But the
J> polymorphism and encapsulation properties of an object API do justify
J> the effort to solve the problems.

I think that the handle-based approach that most cross-language APIs I
have seen suits an object oriented encapsulation well enough. That
encapsulation would have to be done in the target language, though.

One approach to doing that is what Borland did to make Delphi use QT.
QT is a C++ library with a C++ interface, unlinkable by the Delphi
compiler. So they wrapped the C++ classes into a POF- (plain old
functions <g>) based adapter API, with one function for each member
function of each class (plus constructors, destructors & any globals).
All the functions took a handle/pointer to use as "this". They then
wrapped the wrapper into a Delphi class library. This is not the best
possible setup efficiency-wise but it worked. I can't see how one
would make a Firebird C++ API available to languages other than C++
without going through a lower level layer like the one I described
above, which doesn't sound too different from what happens now, except
that now an OO native API is not available even for C++ (but that is
easily solved by bundling IBPP with Fb :-)).

Ciao
--
Nando Dessena
http://www.flamerobin.org