On Fri, Oct 04, 2002 at 12:04:07AM -0700, Brian Ingerson wrote: > Here are a couple use cases: > - Mitchell Charity has written a faster regex based parser. > - He has also written a swig glue layer. > > How do we expose these to the user without making them the default? > > Here's some possibilities: > > use Inline C => DATA => > PARSER => 'regex'; > > use Inline C => DATA => > GLUE => 'SWIG'; > > The defaults would be 'recdescent' and 'XS'. > > Doing things this way requires the support of Inline::C. And it requires > defining an API for plugging in parsers and glue layers. > > Another option is to let Mitchell write
> --- > > It's not clear to me which way to go. Do we want to create a lot of > independent Inline::C flavors that are more independent of Inline, or do we > want one Inline::C with pluggable backends? > > I'm asking for suggestions or a show of hands here. I'd prefer the pluggable backends option. I'd like to be able to happily write my code to work with Inline::C, and then pick and choose months (or years) later whose backend to use, without having to change all my code. I'd like it to say use Inline C => ... and then somewhere at the top level of my script be able to say "I'd like to use Mitchell's regexp parser by default" and have all my modules obey. And then if someone scary writes a C parser in C [er, Inline::C :-)] that's even faster than the regexps, then I only want to change one thing at the top level to use it. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
