On 08/12/14 13:55, Mark Rotteveel wrote: > On Tue, 12 Aug 2014 13:18:31 +0400, Alex Peshkoff <peshk...@mail.ru> > wrote: >>> 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'. > Which is exactly why I said *these types* and not *this type*, the comment > applied to both.
Agreed. Excuse my bad English - I did not notice a difference. But there is one more look at an issue. I very often read in FB-related lists something like - hey, why do you support such useless feature as ... (here may follow a lot of things, for example - embedded access to databases). Sometimes even from developers - why do we support a port to such bad OS. And the only answer known to me is "sorry, if you do not use that feature/port/etc. take into an account that it's required to other 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 >> 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. People use to call C API the "lowest common denominator". OK, but COM (based on VT technology) works fine for a very long time. And if you read MS docs you will find that use of virtual tables is more reliable method for cross-language communication. I can't say which way is more reliable - both work. Use of C API depends upon name resolution in compilers/loaders, use of virtual tables depends upon ability to access that tables as classes/structures/records/arrays/etc. Both depend upon correctly passed parameters (in same registers, in correct order on stack, etc.). When used reasonably both can be made to work. > >> 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++. We will deny part of API if they do not want to use objects. That will be part dedicated to creation of plugins. > I still get the feeling that a solution is chosen before the requirements > and needs are clear. Yes, and therefore this discussion. Suppose that to make it happen we needed at least alpha release - people typically do not reply before they try something. And this discussion certainly gives results - it's clear that providing API only as virtual tables is not enough for many people. OK, we do not want to disattract them from the project. But this may be done in a way not disturbing lower level API. I can give a parallel with C interface to unix kernel - in different unix variants (and on different HW) low-level interface to kernel differs very much. But it does not affect people who use that interface from C - that difference is hidden by a thin layer between kernel and user program. To let people access firebird in a way they prefer we will also provide some thin layer. I hope such solution can help to see a light in the end of this discussion's tunnel. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
