I think it is universally accepted that the Firebird interfaces should be OO. I would like to remind folks that there are at least two ways to do this. One is to define the interface in an OO language. But, as has been widely argued, this is impossible to make compatible across the various OO languages.
Another approach, which I used for the original interface, is to represent objects as abstract handles and use a flat, i.ie. non-OO, interface using handles. Then, on a language by language basis define an extremely thin set of classes that hide the handles and presents a fully functional, native, OO interface that conforms to the conventions, usage, and semantics of the host language. This puts language specific OO class wrappers around the (extended) original OO interface. It is a fool's errand to try to build a OO interface that is call compatible across a wide range of OO languages. If anyone is in doubt, look at Objective-C and weep. In my ancient and grizzled opinion, people are vast more hung up on the low level mechanics of the interface than the high level semantics. Arguing about vtable layout is a waste of everyone's time and, in any case, will never serve all OO languages. Vtables, in the very best of world, make abstract the interface hiding the implementation. But Firebird already has a mechanism that does this, the Y-valve (historical note: my boat has a new Y-valve as part of a new septic system this year). Leverage what you have. Implement language specific interface class wrappers on the original handle based flat interface. Then extend this to support user friendly, industry standard interface semantics, e.g. JDBC, to attract new users. > On Aug 9, 2014, at 4:11 PM, Dmitry Yemanov <firebi...@yandex.ru> wrote: > > 09.08.2014 21:19, Dimitry Sibiryakov wrote: > >>> It has to be channeled to benefit current and prospective users. >> >> Current users don't care about API because they don't use it. They use all >> kind of >> envelopes which are already OO-oriented, tested by years and well >> documented. Future users >> also will use them instead of API because new API has no such features. > > Here we mostly speak about FB API users, not FB users in general (they > really don't care). None of the connectivity layer developers will be > using the new API if it does not provide them with some new features. In > FB3, there are very few of them, but with FB4 the situation may start > looking differently. > > There's also a different aspect, much more important IMO. How hard is to > develop a new connectivity layer (for FreePascal / Node.js / JavaScript > / Haskell / whatever) using our API. The easier it is, the more > prospective users we can get. The SQLDA stuff was sometimes described by > newcomers as PITA to deal with. If the new API, be it OO or "plain C", > can be more user-friendly (in terms of usability and extendability), > then it wins hands down. > > > Dmitry > > > ------------------------------------------------------------------------------ > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
