"Robert Cummings" <robert@xxxxxxxxxxxxx> wrote in message news:4AF7549D.1060005@xxxxxxxxxxxxxxxx > Tony Marston wrote: >> "Eddie Drapkin" <oorza2k5@xxxxxxxxx> wrote in message >> news:68de37340911081330v799803f3he6ed60ecc6e67bdb@xxxxxxxxxxxxxxxxx >> On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston >> <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: >>> That's an amateur fudge, not a professional fix. Besides, what happens >>> if >>> your hosting company won't let you install PECL extensions? >>> >>> -- >>> Tony Marston >>> http://www.tonymarston.net >>> http://www.radicore.org >>> >>> "Eddie Drapkin" <oorza2k5@xxxxxxxxx> wrote in message >>> news:68de37340911081209p45577d46r70a3c194f1079510@xxxxxxxxxxxxxxxxx >>>> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston >>>> <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: >>>>> "It is for the better"? How can you justify that? It is a problem that >>>>> will >>>>> cause a lot of headaches for a lot of users, yet the solution which I >>>>> have >>>>> proposed will remove that problem with only very little effort, yet >>>>> still >>>>> leave only one regex engine which has to be supported in PHP 6. >>>>> >>>>> You have to balance out the small bit of effort required in >>>>> implementing >>>>> this solution against the huge amount of effort required in changing >>>>> thousands, if not millions of scripts. >>>>> >>>>> For the PHP developers to say "we can't be bothered to update the >>>>> POSIX >>>>> functions to deal with unicode, so we've decided to drop them from PHP >>>>> entirely even though it will break lots of scripts" will not go down >>>>> well >>>>> in >>>>> userland. >>>>> >>>>> >>>>> -- >>>>> Tony Marston >>>>> http://www.tonymarston.net >>>>> http://www.radicore.org >>>>> >>>>> "John Black" <spam@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message >>>>> news:4AF70120.1040209@xxxxxxxxxxxxxxxxxxxxxxxxxxx >>>>>> The same can be said about the removal of magic_quotes(), it will >>>>>> break >>>>>> A >>>>>> LOT of old scripts. >>>>>> I am in the same boat, I did not keep up to date with the PHP >>>>>> developer >>>>>> plans and just found out about ereg when I installed PHP 5.3. >>>>>> >>>>>> I think it was handled properly by displaying warning messages before >>>>>> actually removing it. It will give people enough time to update their >>>>>> scripts or weed out the old and insecure scripts. >>>>>> >>>>>> Yes, it will create some headache but, AFAIK, it is for the better. >>>>>> >>>>>> -- >>>>>> John >>>>>> Intelligent Life >>>>>> http://xkcd.com/638/ >>>>> >>>>> >>>>> -- >>>>> PHP General Mailing List (http://www.php.net/) >>>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>> >>>>> >>>> The plan, as far as I am aware, is to move POSIX regular expressions >>>> into PECL as of PHP6. If you can fix your scripts by simply running >>>> "pecl install ereg" what's all the hee-hawing about? >>> >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >>> Then you've got several options: >>> 1) Don't upgrade PHP. >> >> Not an acceptable option. >> >>> 2) Pick a different hosting provider. >> >> Not an acceptable optional. >> >>> 3) Fix your scripts. >> >> The scripts aren't broken. It's PHP 6 that's going to be broken. > > I think you're missing the point of a full version increase. This is not a > minor or micro version change... script breakage is *expected*. But breakage should be kept to an absolute minimum, and developer laziness or incompetence is not an acceptable excuse. > You don't think PHP should support legacy cruft in the core forever do > you? Widely use regex functions are not "legacy cruft". Besides, who decides what is "cruft" and should be removed from the language? > If unicode support is slopped onto the current POSIX regex functions won't > that then make them non-POSIX? Food for thought. Also, why support two > libraries for which one is obviously inferior in speed and functionality? That is why I suggested that instead of dropping the POSIX functions entirely and seriously annoying lots of users, that they should simply be rewritten as wrappers for the PCRE functions. In that way all the calls to ereg_* would still work, but all they would do is immediately call the relevant preg_* function. The small amount of effort that tghis would take would kill two birds with one stone: (1) There would be only one regex engine to support, which would be PCRE. (2) Lots of developers would be spared the hassle of modifying their code as all the calls to POSIX functions would still work as expected because the language would redirect to the PCRE function automatically. I am not suggesting that the POSIX functions be rewritten to deal with unicode as that would require a huge amount of effort, but by redirecting al POSIX calls to the equivalent PCRE function would have the same effect for far less effort. The choice is simple - either a small amount of effort from a small number of developers, or a large amount of effort from a large number of seriously pissed-off users. Do the maths. It's not rocket science. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
