Best Practices for passing option hashes into XS

[Simon Wistow]

On Sun, Apr 28, 2013 at 11:45:04AM +0100, James Laver said:
> I think you've basically got a first question you haven't asked. Are 
> you writing a C library that you want to interface with in perl or are 
> you writing an XS library? If the former, you should probably 
> translate them into a broader structure that includes all of the 
> options you're looking for (or pass them as plain parameters into the 
> remainder of the code). If the latter, you should stick with Perl 
> datatypes.

That's an interesting question and having thought about it for a 
while I have 3 reasons why I'm not happy doing that ...

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.

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.

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.

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.