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.
