Subject | Re: [Firebird-Architect] External Engines (and Plugins) |
---|---|
Author | Dmitry Yemanov |
Post date | 2008-06-24T04:18:08Z |
Adriano dos Santos Fernandes wrote:
implements languages. Instead, it works with calling conventions (and
probably the binary v-table layout) which both are not bound to some
particular programming language (i.e. C/C++ and Delphi can share the
same external engine). So, the term "language" doesn't suit us well and
hence another syntax should be used, even at the cost of not strictly
following the standard.
I don't think such an implementation difference is important enough,
provided that the standard doesn't define the exact relationship between
the LANGUAGE clause and programming languages. But it really can confuse
our users who could think that some existing engine is not suitable for
them while in fact it can serve their needs.
You're arguing that mixing C++ and Delphi is generally a bad idea and
having different engines for them would make things easier for users,
right? Could you please enumerate (again?) what would Delphi users have
to code themselves in order to have their functions working inside a C++
engine? Is it required even for simple functions that don't access the
database?
Dmitry
>Vlad is trying to make a point that our design doesn't actually
>> Can you, please, quote standard or show paragraph numbers which is described
>> LANGUAGE ?
>>
> "An external routine is one whose <language clause> does not specify
> SQL. The <routine body> of an external routine is an <external body
> reference> whose <external routine name> identifies a program written in
> some standard programming language other than SQL.". Search for this
> clauses.
implements languages. Instead, it works with calling conventions (and
probably the binary v-table layout) which both are not bound to some
particular programming language (i.e. C/C++ and Delphi can share the
same external engine). So, the term "language" doesn't suit us well and
hence another syntax should be used, even at the cost of not strictly
following the standard.
I don't think such an implementation difference is important enough,
provided that the standard doesn't define the exact relationship between
the LANGUAGE clause and programming languages. But it really can confuse
our users who could think that some existing engine is not suitable for
them while in fact it can serve their needs.
You're arguing that mixing C++ and Delphi is generally a bad idea and
having different engines for them would make things easier for users,
right? Could you please enumerate (again?) what would Delphi users have
to code themselves in order to have their functions working inside a C++
engine? Is it required even for simple functions that don't access the
database?
Dmitry