On 11/06/2020 11:18, Pavel Cisar wrote:
This is not a problem for languages like Python, Java and .NET that
don't use these files at all, but C++ & Pascal are still important
languages and we should offer some better solution. At least it should
be discussed with those who use them (for example MWA Software,
developer of ibx4lazarus?).
Did I just hear my name mentioned ;)
My main gripe with the new API is really more about documentation than
anything else. It is not easy to work out how to use it except by
experimentation. E.g. with the new DecFloat type I basically had to look
at how the interface returned the BCD format value by using the debugger
to inspect the data at the byte level and then work out how to convert
this (unpacked) format into the packed tBCD record used by FPC and
Delphi - and vice versa. I still don't know how to process an INT128
type except by converting it to a string (!) and then parsing the string.
The "firebird.pas" file is always "processed" before it is taken into
IBX for Lazarus - which is perhaps why I am less bothered about any
imperfections in the source code. The most important need for this is to
extract the type and const declarations and separate them out in order
to avoid name space conflicts between the actual API and IBX, as well as
to limit pollution of the global name space. I also remove the
exceptions generated by the cloop code as I prefer to handle the
exceptional conditions in IBX itself.
The call to get the IMaster interface also assumes static linking with
the client library, while IBX always dynamically loads the fb client
library and then dynamically links to each exported call using
GetProcAddress. This allows IBX to work on systems with multiple copies
of the fb client (very useful for testing) and for the legacy interface
this behaviour allowed it to adjust to different versions of InterBase
(e.g. before and after the services interface was introduced).
The additions to the new API for FB4 don't seem to have introduced any
backwards compatibility issues. The same IBX code works with both
Firebird 3 and Firebird 4 client libraries and uses each interface's
version number to determine whether the FB4 functions should exist. It
will not attempt to call an FB4 function if the version number is too
low. I do agree that there should be a clear scheme for version
numbering as consistent version numbers are really important when it
comes to backwards compatibility.
Tony Whyman
MWA Software
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
