Greetings all,
I'm back from YAPC. It was an excellent conference. Inline was well received. I didn't
even sniff my email, and that was quite refreshing. :) It's good to be back though,
and I'm ready to hack on Inline like never before. I've got plenty of good new ideas,
and even more good old ones. Onward ho.
One idea came up last week, and I thought I'd run it by you. Inline::XS. At first I
thought "Yea gods, please no", but it makes sense. It's just like Inline C except that
you write your C mixed in with your XS. And it's so easy to implement, that I'll just
add it as an option to Inline::C. It's more or less "raw mode".
use Inline C => DATA =>
NAME => Foo =>
ENABLE => 'XS';
greet("Ingy");
__END__
__C__
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
int greet(char* name) {
printf("Hello %s\n", name);
}
MODULE = Foo PACKAGE = main
int
greet (name)
char * name
So why have I just allowed something that could be done so simply, to be done the hard
way? There's a couple reasons.
Most importantly is acceptance. I don't know how how many of you have noticed, but
there is nearly no cross-posting between the Inline and XS mailing lists. And the
seasoned XS hackers almost never write to our list or even me personally. I find this
confusing, since we are all doing the same thing, albeit using different techniques.
There are a lot of very bright people who are still doing XS the old way. :) Since
Inline used in this manner will still provide all the ease of use features, I hope to
trigger more collaboration between groups.
The other reason is that there are still a few things that can be done in XS that
Inline doesn't provide for. It's the 80/20 rule. On one hand, I don't like making the
options too complicated. In other words, the temptation might exist to try and tackle
XS, just because your doing something wrong with your Inline. But for the legitimate
cases, where regular Inline just can't hack it, I want to provide an alternative.
Thoughts?
Cheers, Brian
