Re: PCRE/Extended-POSIX portability in PEAR packages

From: Date: Sun, 22 Aug 2004 18:03:02 +0000
Subject: Re: PCRE/Extended-POSIX portability in PEAR packages
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-32820@lists.php.net to get a copy of this message
Just my 0.02 Some time ago I wrote a simple class for solving this at work, that wrapped some common PCRE and POSIX regex operations, mainly matching. The methods accepted arrays of regexes and input strings. A preg_* only (even more) simplified version that I beautify for a talk last year is in: http://talks.php.net/show/sdphp_using_tools/14 In that old code I used assoc arrays for the regexes, that way you could retrieve the matches for just one of them selectively. If you want I could try and dig out the old complete code and sent it to you, although it is not that complicated to write from scratch. Cheers. --- Philippe Jausions <Philippe.Jausions@11abacus.com> wrote: > Hi, > > I'm trying to find a PEAR solution to the problem of PCRE or Extended > POSIX functions not being compiled into PHP for certain packages that > use them. > > For example sake, let's say I want to use HTML_Template_Flexy but the > PHP installation it is to run under doesn't have PCRE built in. Let's > also assume, that ereg_* functions could work for the package (with > minor adjustments to the pattern syntax.) > > Solutions: > > 1. Make the package dependent on the PCRE extension, > But then we can't use a package that use preg_* in the situation above. > > 2. Add "if (function_exists('preg_replace'))" type of statements > everywhere in the package code, and possibly use the ereg_* functions > instead, > That works fine, but clutters the code a lot. > > 3. Add a "preg_replace()" function to the PHP_Compat package. > A bit complicated to write, and we can't really rely on possible > ereg_* function. > > 4. Create a new PHP_Portable package that defines a "reg_replace()" > function, that will detect which RE extension is available. A bit like > PHP_Compat. > This is my prefered solution: doesn't clutter package code. Possibly > fastest solution, although there is dependency on extra package. Would > also allow for array support for ereg_* functions. > See http://www.11abacus.com/dev/pear/reg_replace.phps > > 5. Define a "regExReplace()" method in PEAR package > Would make it available to all packages but bloat the PEAR package. > > 6. Define a "regExReplace()" method inside the package itself. > Downside is that the "reg_replace()" method would need to be added > to each and every package that could use some portability for RE > functions. Reducing code re-use, but no extra dependencies... > > 7. Define a PHP_RegEx package that would define a "replace()" method. > Same idea as with PHP_Portable but in a class. > > All the above applies to all preg_* and ereg_* functions... But I guess > you all know what I meant. > > Of course if none of PCRE or extended POSIX functions are available, > then the package cannot be used at all. > > One last solution is to provide one new RegEx package plus copy/paste > the necessary code directly into the packages that could use it. This > way we have a library of portable functions available in PEAR and we > limit the dependency on an extra package. > > What do you think? > > -Philippe > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > ===== -- Jesus M. Castagnetto (jcastagnetto@yahoo.com) Research: http://metallo.scripps.edu/ Weblog: http://weblog.castagnetto.org/ PEAR stuff: http://pear.php.net/user/jmcastagnetto __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

« previous php.pear.dev (#32820) next »