Mike,
I'm not sure that I understand 100% what your question is, but I'll try
answering it
with an example.
The Inline API is pretty simple and allows to implement you module in any
way
you want to. You are not forced to dynamically link a C library and bind
it's functions.
In fact you are not obliged to use any C code at all (directly) to glue your
language to Perl. You can do it any way to like. The only thing that's
implied it that
the resulting interface be a certain number of Perl subroutines that "map"
to your
"language"'s code.
Let's take for example Inline::SQL. Say you want provide the following usage
for
this module:
use Inline (
SQL => 'DATA',
SERVER => 'db',
DATABASE => 'db',
LOGIN => 'sa',
PASSWORD => 'xxx'
) ;
my $name = "Joe" ;
my $user = get_user_by_name($name) ;
print "Joe is $user->{age} years old\n" ;
__END__
__SQL__
/*get_user_by_name*/
select * from users where name = '$arg0'
The Inline API will require you to provide, among others, 2 methods: 'build'
and 'load'
Normally the build function receives the code, compiles it (or whatever that
means in
your context), and creates somekind of object file (again this is in
whatever format you choose).
The load function then would normally load the object file and bind certain
function/classes to Perl.
Here's how one could implement the guts of this module:
build:
Grab the code, extract the first line and clean it up. That's the function
name (get_user_by_name).
Put that and the rest (SQL code) in the object file.
load:
Read the SQL from the object file. Create a Perl subroutine
get_user_by_name() (using eval)
that calls some other internal Inline::SQL method (say
Inline::SQL::query_one_row) to do the real job.
In Inline::SQL::query_one_row: Substitute the tokens by the provided
arguments and create the
SQL query.
Now one could use DBI to connect to the server, prepare and execute the
query and then return a
hash as the result set. But then one could also choose to use IPC::Open3 and
launch 'isql'
or whatever command line tool, process the output from that and return the
same hash as
the result set.
You decide on your implementation (although in this case I would suggest the
first one... :).
Hope this helps,
Patrick
Note: I cooked this stuff up in a hurry so please pardon any mistakes on my
part.
----- Original Message -----
From: "James Michael DuPont" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 25, 2002 11:56 AM
Subject: Question about Callbacks and Inline Backends
> Dear Inline Users,
>
> Here is a question about the possibility of the
> implementation of an Inline module using callbacks.
> (Note that I have not studied the internals of inline
> yet, but I figured that asking would be the fastest
> way to figure this out)
>
> Lets say that you want to get access to the results of
> the inline code just after compiling from the backend
> system.
>
> For example, imagine Inline::SQL that will allow you
> to embed a sql statement.
> Then imagine a "showplan" statement that will show you
> how the query will be executed, but return it as perl
> data structure.
>
> When you want to do the showplan or execute the
> statement you can get a DBI connection object filled
> with the results.
>
> Now imagine inline::DCE::RPC that will run the IDL
> text through an IDL compiler and return a perl object
> that describes the IDL via a in-memory object.
>
> Do such applications fit into inline, and how would
> you get the results back from the backend assuming
> that you dont want to use intermediate files?
>
> Would you have to register callbacks?
>
> Mike
>
>
> =====
> James Michael DuPont
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
