Don't use XS code

From what I have read about the recently announced Ponie project - we will now be able to port XS code over to run on Parrot. From the Ponie FAQ:

The guts of Perl 5 will be ripped out and made to work using Parrot PMCs rather than Perl 5 Sv structures, which will mean it will be compatible with Perl 6 . Any XS-based code that uses the published Perl 5 API should work fine without any problems. Anything that was marked for deprecation in Perl 5.8.0 will be deprecated in Ponie.

Liz

I'll somewhat disagree with Abigail-II and Elian.

Yes, if you want to interface Perl5 to a C library, then doing so via Inline::C is more likely to make it easy to port to Perl6 than using XS would (the XS porting might be available sooner, but you have much more risk of doing something that won't be handled if you use XS, IMHO).

Using Inline::C or XS to manipulate Perl data structures is something I simply don't recommend and I find that avoiding it when interfacing a library usually makes for a better design anyway.

C code that manipulates Perl data structures has always been the first thing to break when Perl is upgraded. So asking how to do that with Perl6 in mind calls the answer "Don't!" to mind (which is my answer anyway, just not as emphatically).

So when someone asks how to use XS with Perl 6 in mind, my advice is "Don't manipulate any Perl data structures in C and use Inline::C instead of XS." But, that is my advice anyway (again). And I'll bet that modules that follow that advice will eventually be able to work with Perl 6 without requiring any "by-hand" porting.

                - tye

I'll somewhat disagree with Abigail-II and Elian.

Yes, if you want to interface Perl5 to a C library, then doing so via Inline::C is more likely to make it easy to port to Perl6 than using XS would (the XS porting might be available sooner, but you have much more risk of doing something that won't be handled if you use XS, IMHO).

YHO would be very incorrect in this case. The issues involved are entirely those of the perl API, and have nothing to do with the means to generate the C code to access that API. There are no problems one will encounter with XS that one won't in Inline::C, and vice versa.

The means of generating the C code has no bearing on the potential level of trouble. The issues are entirely ones of the perl API.

Considering that Inline::C is just a layer over XS, I don't think so. (And can Inline::C already deal with modules using C?)

Abigail

At least Inline::C's abstraction layer could be easily ported to Perl 6. If inside your C code you're doing stuff to Perl (5)'s internals without using the proper macro's, then of course you're on your own.

So I guess I would put using Inline::C for a new Perl 5 project over using XS, especially knowing that Inline::C will be in the 5.10 core.

Liz

No, it doesn't. The issue, such as it is, is with perl's API. XS is just a thin and somewhat brain-damaged macro layer over C, as is Inline::C. (Which, granted, is far less brain-damaged)

Any non-specious reason to not use XS applies to Inline::C as well.

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality