Subject | Re: [Firebird-Architect] Re: External procedures: implementation proposal. |
---|---|
Author | Jim Starkey |
Post date | 2005-07-27T16:03:19Z |
evgeneyputilin wrote:
don't need another one. I want everything inside the engine that deals
logically with result sets to be able to the use same API. We will
shortly have an RsbResultSet class in the RecordSource type hierarchy to
pump records out of an instance of ResultSet. I want to be able to use
the same code for InternetResultSet, results returned by external
procedures, and maybe UDFs some day. If everyone want to invent their
very own interface, this can never happen.
So, if you want to play in the engine, you have to accept engine
conventions. One of those conventions is the ResultSet abstract
interface class. Use it.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>What? We define termin and describle it'sWe already have a ResultSet interface in use inside the engine. We
>
>We can use namespace for splip this term in code. Or you have rigth
>for exlusive use of this word? Please inform me.
>
>We can't use you ResultSet interface(pure virtual class in C++ term)
>for External Procedue if they don't approach for this task.
>
>
>
don't need another one. I want everything inside the engine that deals
logically with result sets to be able to the use same API. We will
shortly have an RsbResultSet class in the RecordSource type hierarchy to
pump records out of an instance of ResultSet. I want to be able to use
the same code for InternetResultSet, results returned by external
procedures, and maybe UDFs some day. If everyone want to invent their
very own interface, this can never happen.
So, if you want to play in the engine, you have to accept engine
conventions. One of those conventions is the ResultSet abstract
interface class. Use it.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376