Re: [Firebird-devel] New Interface

2014-08-09 Thread Dimitry Sibiryakov
09.08.2014 0:38, Adriano dos Santos Fernandes wrote: > As we tend to adopt an IDL processor, we tend to autogenerate these > Delphi/FPC classes in a way it 1) works 2) is good enough to use, like > the C++ binding. Autogeneration has one disadvantage: it just a waste of time. You somehow forge

Re: [Firebird-devel] New Interface

2014-08-09 Thread Tony Whyman
All this heat is not useful. Yes, of course Delphi and Free Pascal use a non-standard ABI. That's because there is no standard. Likewise, C++ compilers also have a "non-standard" ABI. In the absence of standards all we can do is default to the lowest common denominator and, in practice, that us

[Firebird-devel] Handling isc_arg_interpreted in a statusvector

2014-08-09 Thread Mark Rotteveel
Currently jaybird is handling isc_arg_interpreted the same as isc_arg_string and assumes it is a message parameter for the message of the previous error code. However I was just debugging the handling of the statusvector for the new native client wrapper in Jaybird and I noticed - when trying t

Re: [Firebird-devel] dtype_packed

2014-08-09 Thread Ann Harrison
> On Aug 5, 2014, at 5:50 AM, Dmitry Yemanov wrote: > > 05.08.2014 12:19, Mark Rotteveel wrote: > >> it seems that dtype_packed is also known in >> COBOL (and SAP) for a BCD (binary coded decimal). > > dtype_packed really seems to be a packed decimal, however it's not used > by Firebird since

Re: [Firebird-devel] New Interface

2014-08-09 Thread Tom Coleman
On Aug 9, 2014, at 6:26 AM, Tony Whyman wrote: > All this heat is not useful. Some heat is good. It's an indication of underlying passion, and one would expect developers to be passionate about Firebird. That passion however should not be about promoting one's own personal programming bias

Re: [Firebird-devel] New Interface

2014-08-09 Thread Dimitry Sibiryakov
09.08.2014 19:13, Tom Coleman wrote: > It has to be channeled to benefit current and prospective users. Current users don't care about API because they don't use it. They use all kind of envelopes which are already OO-oriented, tested by years and well documented. Future users also will use

Re: [Firebird-devel] COM for Plugins

2014-08-09 Thread marius adrian popa
I vote with Jim on this , if we reinvent com at least we can use it as it should , I would use xpcom from mozilla https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM On Sat, Aug 9, 2014 at 12:30 AM, Jim Starkey wrote: > Isn't COM a natural technology for plugins? Load a module, lookup th

Re: [Firebird-devel] COM for Plugins

2014-08-09 Thread Dimitry Sibiryakov
09.08.2014 19:29, marius adrian popa wrote: > I vote with Jim on this , if we reinvent com at least we can use it as > it should , I would use xpcom from mozilla Mozilla? That slow and hungry-for-RAM browser?.. I would be very sceptical about anything from them. -- WBR, SD.

Re: [Firebird-devel] New Interface

2014-08-09 Thread Dmitry Yemanov
09.08.2014 21:19, Dimitry Sibiryakov wrote: >> It has to be channeled to benefit current and prospective users. > > Current users don't care about API because they don't use it. They use all > kind of > envelopes which are already OO-oriented, tested by years and well documented. > Future users

Re: [Firebird-devel] New Interface

2014-08-09 Thread Adriano dos Santos Fernandes
Someone told abstract Delphi classes was compatible with the C++ vtable, but FPC wasn't. I did some tests and detected that FPC class with or without virtual methods has a pointer in its start. >From this pointer, however, the vtable is not compatible with C++. But we can autogenerate classes fo