Hello all. I've been reading through the Inline::C docs lately and this
section strikes me as pure FUD:
All of this functionality is available through XS macro calls as well.
So why duplicate the functionality? [ ... ] Third, for future
compatibility. It occurred to me that if a lot of people started using
XS macros for their C code, the interface might break under Perl6. By
using this set, hopefully I will be able to insure future
compatibility of argument handling.
Of course, if you use the rest of the Perl API, your code will most likely
break under Perl6. So this is not a 100% guarantee. But since argument
handling is the most common interface you're likely to use, it seemed like
a wise thing to do.
Why is this FUD?
1) The Inline::C macros are no more portable to future Perls than
the XS they wrap. If we can make the Inline::C macros work in Perl 6
then we can just as well wrap the XS macros. Neither is *at all*
certain: Parrot isn't even a stack machine!
2) Perl 6 is years away from replacing Perl 5 and not even fully
designed yet. Using it as a reason to do anything in Perl 5 is
highly suspicious.
Why do I think it matters? From the perspective of an XS programmer the
"improved" Inline::C macros are probably the hardest pill to swallow.
After all, cryptic macros make the C programming world go round. Seeing
big ol' Java-style identifiers smacks of Pascal programmers doing:
#define BEGIN {
#define END }
If gaining XS converts is on the game-plan (and I think it should be) I
suggest we drop the macro FUD from the docs. Let's document the wrappers
as exactly what they are: a convenience for people unfamiliar with the
Perl API. That way XS programmers can happily go on typing ST() and
XPUSHs() without having to worry about some nonexistent portability issue.
Ahhhh, I feel much better now. Back to work.
-sam
