Best Practices for passing option hashes into XS
simon at thegestalt.org
Sun Apr 28 16:33:03 BST 2013
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
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
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
More information about the london.pm