> On Aug 10, 2014, at 3:51 PM, Dimitry Sibiryakov wrote:
>
> 10.08.2014 20:33, Adriano dos Santos Fernandes wrote:
>> It does not make any sense to write a COM-plugin that could just say,
>> "hey, I'm a plugin" and do nothing.
>
> You seem don't understand one things about plugins: they don't
Regression(?) in 3.0: compiler requires explicit name for column which is
reference to built-in context variable and is specified in CURSOR declaration
statement
---
10.08.2014 20:33, Adriano dos Santos Fernandes wrote:
> It does not make any sense to write a COM-plugin that could just say,
> "hey, I'm a plugin" and do nothing.
You seem don't understand one things about plugins: they don't need to do
anything but
respond to engine's calls. Exactly for thi
On 10-08-2014 15:29, Jim Starkey wrote:
> It has been pointed out that the client and plugin APIs are used by different
> types of developers for different purposes. You didn't respond, so it's hard
> to know whether you disagreed, didn't understand the point, or just didn't
> care.
>
> There
It has been pointed out that the client and plugin APIs are used by different
types of developers for different purposes. You didn't respond, so it's hard
to know whether you disagreed, didn't understand the point, or just didn't care.
There is no benefit to forcing two completely different int
> On Aug 10, 2014, at 12:12 PM, Adriano dos Santos Fernandes
> wrote:
>
>
> Writing wrappers around handlers is just something that does not make
> sense in the easy-of-use point of view. If you disagree, I'm waiting for
> your prototype here!
Uh, I've done at least a dozen. Take a look at V
Let me tell a little more about this.
10.08.2014 17:55, Dmitry Yemanov wrote:
> UDRs must use a regular application API for callbacks into the engine,
> this is a design requirement.
It is a very reasonable requirement. But technically it means only two
things:
1) Provider (engine) must be a
10.08.2014 18:31, Adriano dos Santos Fernandes wrote:
> Why do you keep arguing about vtables if the thing you want is just not
> see any change, because you do not want to re-write your applications to
> use the new thing?
Hmmm, altruism, perhaps. I'm trying to save other's butt from the pain
On 10-08-2014 13:20, Dimitry Sibiryakov wrote:
> 10.08.2014 18:07, Adriano dos Santos Fernandes wrote:
>> What I'm actually saying is that inserting a dummy entry in instances
>> and vtable, we make free for use our objects in the languages who uses
>> such layout with variations.
>
>You can i
10.08.2014 18:07, Adriano dos Santos Fernandes wrote:
> What I'm actually saying is that inserting a dummy entry in instances
> and vtable, we make free for use our objects in the languages who uses
> such layout with variations.
You can insert whatever to anything, but...
Delphi/Lazarus pro
On 10-08-2014 05:30, Dimitry Sibiryakov wrote:
> 10.08.2014 10:20, Dimitry Sibiryakov wrote:
>> they are QueryInterface, AddRef, releaseRef.
>
>Oops, I was too quick. Here are details:
>
> http://www.freepascal.org/docs-html/prog/progsu167.html#x211-2240008.2.12
> http://www.freepascal.org/do
10.08.2014 17:55, Dmitry Yemanov wrote:
> UDRs must use a regular application API for callbacks into the engine,
> this is a design requirement.
Right. But "use API" and "has API" are different things. I don't understand
why Adriano
ties them into one.
--
WBR, SD.
--
10.08.2014 17:50, Adriano dos Santos Fernandes wrote:
> I do not see any sane reason to create two flavor of APIs for a thing
> which must be integrated.
They mustn't. End user application doesn't work with plugins. It works with
Y-valve
(and in the worst case - with a provider directly).
10.08.2014 19:45, Dimitry Sibiryakov wrote:
> When will you start to separate application API and plugin API?..
UDRs must use a regular application API for callbacks into the engine,
this is a design requirement.
Dmitry
On 10-08-2014 12:45, Dimitry Sibiryakov wrote:
> 10.08.2014 17:41, Adriano dos Santos Fernandes wrote:
>> And none of this are passed from your library to Firebird, i.e.,
>> plugins, external routines.
>
>When will you start to separate application API and plugin API?..
>
I do not see any sa
10.08.2014 17:41, Adriano dos Santos Fernandes wrote:
> And none of this are passed from your library to Firebird, i.e.,
> plugins, external routines.
When will you start to separate application API and plugin API?..
--
WBR, SD.
On 10-08-2014 12:32, Dimitry Sibiryakov wrote:
> 10.08.2014 17:12, Adriano dos Santos Fernandes wrote:
>> Writing wrappers around handlers is just something that does not make
>> sense in the easy-of-use point of view. If you disagree, I'm waiting for
>> your prototype here!
>
>Why a prototype
10.08.2014 17:12, Adriano dos Santos Fernandes wrote:
> Writing wrappers around handlers is just something that does not make
> sense in the easy-of-use point of view. If you disagree, I'm waiting for
> your prototype here!
Why a prototype? FIB+, IBX, UIB, IBObject - all of them are "wrappers a
On 10-08-2014 07:15, Dimitry Sibiryakov wrote:
> 10.08.2014 12:04, Dmitry Yemanov wrote:
>>> However, apparently FB devs don't think it's important to keep it in
sync with the C++ interface - even if third parties could submit patches
for that.
So in effect, new FB (features) wi
Dmitry, these questions are a good starting point.
To design (or select) an interface, you must start with a solid idea of who the
users will be, their skill level, how they will use it, and where you want to
go with the product.
For example, the original interface targeted two classes of usage
10.08.2014 14:02, Dmitry Yemanov wrote:
> If this is found being impossible
IMHO, it is possible, but not by reinventing VMT for everyone: users of
incompatible
compilers just have to use structures and pointers to emulate "standard" VMT.
Democracy
works in this case.
> 1) Do we keep the e
10.08.2014 14:10, Jim Starkey wrote:
> It is a fool's errand to try to build a OO interface that is call compatible
> across a wide range of OO languages. If anyone is in doubt, look at
> Objective-C and weep.
If this is found being impossible (I'm not deeply involved, so I don't
have a stron
10.08.2014 14:09, Dimitry Sibiryakov wrote:
> Whole project is inherited, remember?.. You have to maintain code written by
> Jim, Mike,
> Arno, Nikolay and others, so why not mine?..
Everything depends on the patch. There's a difference between *can* be
accepted and *will* be accepted. If you c
10.08.2014 12:10, Jim Starkey wrote:
> Leverage what you have. Implement language specific interface class wrappers
> on the original handle based flat interface. Then extend this to support
> user friendly, industry standard interface semantics, e.g. JDBC, to attract
> new users.
When I t
10.08.2014 12:04, Dmitry Yemanov wrote:
>> However, apparently FB devs don't think it's important to keep it in
>> >sync with the C++ interface - even if third parties could submit patches
>> >for that.
>> >
>> >So in effect, new FB (features) will not be compatible with any language
>> >that does
On 10/08/2014 12:04, Dmitry Yemanov wrote:
> 10.08.2014 13:55, Reinier Olislagers wrote:
>
>> However, apparently FB devs don't think it's important to keep it in
>> sync with the C++ interface - even if third parties could submit patches
>> for that.
>>
>> So in effect, new FB (features) will not
I think it is universally accepted that the Firebird interfaces should be OO.
I would like to remind folks that there are at least two ways to do this. One
is to define the interface in an OO language. But, as has been widely argued,
this is impossible to make compatible across the various OO
10.08.2014 12:01, Dmitry Yemanov wrote:
> it may be either accepted or rejected. Because you may disappear
> tomorrow but the project will have to maintain your patch till the end
> of life.
Anyone may disappear tomorrow. "A human being to be mortal is not a problem.
The
problem is that somet
10.08.2014 13:55, Reinier Olislagers wrote:
> However, apparently FB devs don't think it's important to keep it in
> sync with the C++ interface - even if third parties could submit patches
> for that.
>
> So in effect, new FB (features) will not be compatible with any language
> that does not hav
> However, apparently FB devs don't think it's important to keep it in
> sync with the C++ interface - even if third parties could submit patches
> for that.
This is not true
Regards,
Vlad
--
Firebird-Devel mailing l
10.08.2014 13:48, Dimitry Sibiryakov wrote:
> It is an open project, no?..
It is. But open <> unmanaged.
> When C API missed a new feature that I could use, I created a patch,
> submitted it to
> the project and
it may be either accepted or rejected. Because you may disappear
tomorrow but the
On 10/08/2014 11:44, Dimitry Sibiryakov wrote:
> 10.08.2014 11:11, Reinier Olislagers wrote:
>> Of course, my view is that it should be the other way round: FB should
>> be compatible with languages, but your answer is clear enough.
>
>It is compatible. It's C++ interface is compatible with MS
10.08.2014 11:09, Dmitry Yemanov wrote:
>> >and updated with new features for each FB release?
> Not necessarily correct.
It is an open project, no?..
When C API missed a new feature that I could use, I created a patch,
submitted it to
the project and now C API _does_ support a new feature
10.08.2014 11:11, Reinier Olislagers wrote:
> Of course, my view is that it should be the other way round: FB should
> be compatible with languages, but your answer is clear enough.
It is compatible. It's C++ interface is compatible with MSVC and GCC. It's C
interface
is compatible with every
On 10/08/2014 10:40, Dimitry Sibiryakov wrote:
> 10.08.2014 10:34, Reinier Olislagers wrote:
>> If not, it seems quite drastic to require C++ compatibility for
>> languages that may not even have C++ compatibility envelopes
>
>Compatibility and interoperability are right things. Implementing t
10.08.2014 12:34, Reinier Olislagers wrote:
> Do I understand correctly that the existing FB 2.5 C API will therefore
> remain supported
Correct.
> and updated with new features for each FB release?
Not necessarily correct.
Dmitry
10.08.2014 10:34, Reinier Olislagers wrote:
> If not, it seems quite drastic to require C++ compatibility for
> languages that may not even have C++ compatibility envelopes
Compatibility and interoperability are right things. Implementing them is a
gain for
every compiler/language in the worl
On 10/08/2014 09:48, Dimitry Sibiryakov wrote:
> 10.08.2014 5:09, Adriano dos Santos Fernandes wrote:
>>From this pointer, however, the vtable is not compatible with C++.
>If class layout in FPC is incompatible with C++, it is FPC problem.
>They must either fix their layout or implement com
10.08.2014 10:20, Dimitry Sibiryakov wrote:
> they are QueryInterface, AddRef, releaseRef.
Oops, I was too quick. Here are details:
http://www.freepascal.org/docs-html/prog/progsu167.html#x211-2240008.2.12
http://www.freepascal.org/docs-html/prog/progsu168.html#x212-2250008.2.13
--
WBR, S
10.08.2014 10:00, Dmitry Yemanov wrote:
> From what I've seen on the web, there should be three pointers there.
Sure: they are QueryInterface, AddRef, releaseRef.
Worth reading, especially comments:
http://sergworks.wordpress.com/2011/12/08/why-we-need-interfaces-in-delphi/
--
WBR, SD
10.08.2014 10:00, Dmitry Yemanov wrote:
> From what I've seen on the web, there should be three pointers there.
> But maybe it depends on the compiler settings or other reasons (like for
> RTTI and multiple inheritence in gcc).
One of settings that must be taken into account:
http://www.freep
10.08.2014 07:09, Adriano dos Santos Fernandes wrote:
> I did some tests and detected that FPC class with or without virtual
> methods has a pointer in its start.
From what I've seen on the web, there should be three pointers there.
But maybe it depends on the compiler settings or other reasons
10.08.2014 5:09, Adriano dos Santos Fernandes wrote:
> I did some tests and detected that FPC class with or without virtual
> methods has a pointer in its start.
Don't forget to test interfaces instead of classes.
--
WBR, SD.
---
10.08.2014 5:09, Adriano dos Santos Fernandes wrote:
>From this pointer, however, the vtable is not compatible with C++.
>
> But we can autogenerate classes for good usage in Delphi/FPC if we put a
> dummy pointer both in our vtable (the template demo) and in object
> instances.
If class layout
44 matches
Mail list logo
