Best Practices for passing option hashes into XS

[James Laver]

On 28 Apr 2013, at 16:33, Simon Wistow <simon at thegestalt.org> wrote:

> Firstly, while technically the C code written for the module is never 
> used anywhere else. However I didn't write it originally - I'm merely 
> patching it - and it currently doesn't use any Perl datatypes anywhere 
> else so I'm loathe to add Perl datatypes for that reason.

That sounds awfully like a compatibility shim for perl. Where using Perl datatypes would be appropriate.

> Secondly, I have also, several times in the past, wanted to appropriate 
> C code I've written or observed in Perl modules (also Ruby, PHP and 
> Python extensions) and use them elsewhere and the use of Perl Datatypes 
> prevents that.

Ultimately you still need some sort of shim. Sounds like you're actually writing a reasonable amount of C and that it would be better off being a C library in and of itself.

> Lastly, an aesthetic choice. The language Perl is written in is 
> technically C but really, it's not. It is great for writing Perl but 
> it's not what you'd call pretty or easily accessible. 
> 
> Moreover it *looks* different to 'regular' C. The code I'm modifying is 
> written in nice (to my eyes) lower_case C dialect. The code I'm adding 
> is OpenSSL Camel_case and the juxtaposition makes me wince. Adding in a 
> third style might be too much to bear.

But it has to go somewhere. You still need shim code somewhere.

> If I was going to add a fourth (less well thought out) reason it would 
> be that, like dates and string encodings, one should get ones data into 
> a canonical form as close to the 'edge' as possible. In this case all my 
> XS and Perl code is in the .xs file and all the C is in .c file and 
> never the twain shall meet. I suppose this is just the second point 
> again.

Again, I think it comes down to that question. It sounds like you're writing a C library and a perl shim in the same chunk of code. You should think about separating them.

James