On Tue, 12 Aug 2014 13:18:31 +0400, Alex Peshkoff <[email protected]> wrote: >> On Tue, 12 Aug 2014 10:37:21 +0400, Alex Peshkoff <[email protected]> >> 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'.
Which is exactly why I said *these types* and not *this type*, the comment applied to both. >> 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... That is not how I read and interpret this discussion, and I get the impression others have the same feeling. > 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. Auto-generation seems nice, but if done incorrectly leads to a hard to use API or an unstable API because minor changes might escalate to unwanted or unforeseen changes to said API. Also the *expose part of the API* seems to suggest that it will deny users part of the API if they don't want to go C++. I still get the feeling that a solution is chosen before the requirements and needs are clear. Mark ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
