On 08/12/14 12:13, Mark Rotteveel wrote: > <53e9b621.5050...@mail.ru> > Message-ID: <e1539af719bd359c5254c41730071...@imap.procolix.com> > X-Sender: m...@lawinegevaar.nl > User-Agent: RoundCube Webmail/0.2 > > On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff <peshk...@mail.ru> > wrote: >> On 08/11/14 22:29, Tom Coleman wrote: >>> I interface a proprietary language with Firebird, Oracle, and >>> Sybase/MS-SQL. >>> >>> There is never any case where I would want to see std:exception. >>> >>> Could it be time to start thinking about burying this idea that is >>> looking more and more like a sacred cow? >> Tom if _you_ do not want to use one of the most powerful features of >> programming languages, please do not suggest others not to use it. > I think these types of response are not constructive and only serves to > alienate people.
That was an answer to 'sacred cows'. > Please keep in mind that apart from the core developers, everyone here is > discussing as an external consumer of this API. And unfortunate as that may > be, an API for external consumption by disparate systems should cater to > the lowest common denominator; and unfortunately that seems to be a C API > (or in my case: the wire protocol *and* the C API). > > The fact that the Firebird core team prefers to use a C++ abstraction > inside Firebird is an entirely different discussion. By all means: use a > C++ API internally, but external exposure of this API - unless a better > solution comes up (and I still haven't read the entire discussion so I may > have missed something) - must be as simple as possible But that is exactly what we suggest... > and preferably > 'industry-standard' (for whatever that is worth), which means C and not > some complex and - probably - undocumented home-brew calling mechanism that > makes life hard for consumers of the API. > > The main point of an API is to allow developers to *use* Firebird, so > please do not alienate those users as their concerns are valid and should > be taken into account. And if people already using Firebird voice those > concerns, what do you think happens if people evaluate Firebird for use? If > the choice is between a legacy API that doesn't expose all (modern) > features of Firebird or a C++ API that is only really usable from C++ or > requires catering to the demands of some weird calling mechanism (note: I > am exaggerating), then they'd probably take their business elsewhere. Suggested approach makes it possible to automatically generate C API based on C++ API. This code will be certainly entirely C++ itself, but will make it possible to automatically expose part of new API as plain-C functions. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
