On Aug 11, 2014, at 12:06 PM, Lester Caine wrote:
> On 11/08/14 12:53, Alex Peshkoff wrote: >>> IBPP can >>>> still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would >>>> act the same for Delphi, etc. They just need to be ported to the new >>>> core API (whatever it will be). >> I agree with this is POV 100%. > > I've been following the debate on 'new interface' and to be honest I > still don't understand where the problem is. Having used IBObjects on > legacy projects, that has not been used for a long time as I am now > reliant on PHP and Jaybird these days to pull results from Firebird. > Neither of these need an internal interface weight down by C++ and I'm > sure a lot of power users are in the same boat? C++ is a layer on top of > the connection to the database and I'm sure if I need to revert to that > I'd be looking to IBObjects again, but certainly windows will not be > featuring in that which ever way I go. On Aug 11, 2014, at 2:08 PM, Adriano dos Santos Fernandes wrote: > No one is telling to pass exceptions across modules, it's quite the > contrary. The generated impl. wrapper is going to guarantee that not > happens in the Firebird code. > > But an (client) application wants to generate exception when accessing > the API, and we do not know in advance what's the good classes for each > project. > > Some may use like Firebird, an Exception not inherited, others wants > std::exception, a Qt-based project would want another one... 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? ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
