Brian Ingerson wrote:
> The implementation of such a feature would be easy. I think it's the
> syntax/markup that I'm struggling with. How can we write C code that
> tips off Inline to do prototyping behaviour. Inline C needs to remain C,
> so I can't go adding extra markup there. I could add a PROTOTYPE option
> so you could say:
>
> use Inline C => DATA => PROTOTYPE => 'handle_array (\@)';
> __END__
> __C__
> void handle_array(SV*) { ... }
>
> But I don't like the way it scales, and it seems like a lot of wasted
> effort to do my own protoype parsing.
my ever-developing coroutines module is currently using an optional
PROTO => '\@',
to handle this issue. It would be good to have a somewhat standard
syntax for stuff that accepts a hash and produces subroutines.
> I thought of this idea, which I like better, at least for your example:
>
> use Inline C;
> __END__
> __C__
> void handle_array(AV*) { ... }
>
> This is completely valid C. An AV* is just a variant of an SV*. But it's
> a syntactic cue to Inline to make sure it generates the proper XS
> prototype. I think this would work, but I just came up with it right
> now. Anybody see problems with this?
the names of the new types that cue Inline might collide with names in
an application space? What if you want to use an AV as the type, but not
generate a prototype?
How about embedding the prototype declaration in a C comment?
use Inline C;
__END__
__C__
void handle_array(SV*) /* \@ */ { ... }
that would look closer to a prototyped perl subroutine definition.
My off-the-somewhat-worn-cuff reccomendation, FWIW, is to support
all three.
