<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. 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 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. Mark ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
