On 12/08/14 09: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. > > 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.
That is a nice detailed expansion on my comment about c++ being secondary. The PHP project is currently discussing how to get back to using Unicode and new modern API's and C++ has already been ruled out. Everything will remain 'C' in the core as will extensions to other sources such as Firebird ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
