On Mon, 4 Jun 2001, Brian Ingerson wrote: > In case anyone hasn't got the message, as of 0.50, there will be no > advantage *whatsoever* in writing extension modules in XS instead of > Inline. The only exception is if you are doing something very fancy in > XS that Inline doesn't (YET) provide. If this is the case for you, call > me toll-free. I want to talk with you. Do you really want to replicate all of h2xs? What are your plans regarding typemaps? Why the desire to kill XS? From my point of view Inline::C is the least interesting of the Inline modules - it provides a service already pretty well provided for (minus a stiff learning curve or two). Much more interesting are the non-C Inlines - they provide a totally new facility. May I humbly suggest you refocus your rhetoric? > There *are* major advantages to using Inline though. Besides the ease of > development, all of your C code will remain inside your module where > people can look at it, *and* modify it. Large C projects usually benefit from a multiple file sources. Putting everything in one file is not necessary such a good thing. Consider that expressing a simple construct in C often takes many more lines than a similar construct in Perl. As a result a Perl module implemented in C is not necessarily small enough to usefully fit in a single Perl file. > This is good for the community, good for open source, and good for > Perl. (Normally the C code disappears from your system after > compilation/installation) That sounds more like a bug in ExtUtils::MakeMaker than a flaw in XS (or are they the same thing?). Maybe Perl should maintain a "site_src" next to "site_lib"... In general traditional multi-file C programs haven't posed much of an impediment to Open Source - even when the binaries are distributed without the source directly accessible (RPMs, for example). -sam
