Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Paul Fierro wrote: On 11/9/09 8:56 AM, Tony Marston wrote: I have tried subscribing to the internals list, but none of my postings ever appears. That's unfortunate as you missed this thread: http://marc.info/?t=12553625831&r=1&w=2 I didn't :) 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: "David Otton" wrote in message news:193d27170911090331k7ecbe69cl1dd30651273e7...@mail.gmail.com... 2009/11/9 Tony Marston : So you wouldn't trust the PHP developers to write simple code which takes each POSIX function and redirects it to a PCRE function? I have more faith in their ability than I do yours. If it's as simple as you claim, why don't you mock-up your solution in PHP, rather than C? Because I can't do that until I install PHP 6, but as I never play with beta software waiting for it to go live will be too late. Don't be lazy Tony, install beta software... make sure your software is ready before the beta becomes release software. This is part of being "professional". 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: "Ashley Sheridan" wrote in message news:1257764339.1076.56.ca...@localhost... On Mon, 2009-11-09 at 00:23 +, Tony Marston wrote: developer laziness or incompetence is not an acceptable excuse. Exactly, so fix your scripts! But my scripts aren't broken! It's PHP 6 that is broken. Actually when PHP 6 comes out... it will be your scripts that are broken. The language doesn't adapt to you for every version change. YOU adapt to the language, otherwise YOUR scripts ARE broken. Some hosting companies won't allow you to use htaccess files, refuse to install any optional extension, let alone one from the PECL or PEAR repositories. Some of them won't give you more than one MySQL database. Different companies provide different levels of service. The only thing that the DO have in common is that they charge you for it. Then switch hosting company. Or pony up the extra $5 or $10 per month or so for a VPS that gives you root access and all the configurability you could want. Lack of choice is NOT the fault of PHP. 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: "Robert Cummings" wrote in message news:4af76e1f.2050...@interjinn.com... Tony Marston wrote: "Robert Cummings" wrote in message 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. Not quite true... major version moves are an opportunity to make a break for freedom. All there needs to be is an upgrade path... and that is clearly in play right now with the warning indicating that POSIX regex functions are being deprecated. But a lot of people won't see those warnings until they run 5.3.0 for the first time. It is common practice, at least in all the other languages that I have used, that is something is going to be removed that it is marked as deprecated at the start of the previous release, not at the end. So marking the POIX functions as deprecated should have happened in 5.0, not 5.3. This is PHP, it is not all the other languages you have used. That said, it will probably be at leats a year before PHP6 even thinks about being released. 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? They most certainly are cruft. That is just your opinion. And the opposing opinion is your... all just opinions right?! Other people think that PHP should be rewritten so that it appears more like their favourite language. Among the suggestions I have seen are: - make all variables statically typed instead of dynamically typed. - remove all procedural functions and make the language "pure" OO. Who decides if they are right? The PHP team... primarily those who contribute to the PHP cod itself. Those people have earned the privilege of making final decisions. .. hence the reason they are being removed. The people who decide what is, and is not, cruft are the very same people who are writing the code. If you are not happy with this then there's the age old saying in open source... "put up or shut up". I can't because I don't program in C. So I shall do the nextbest thing - complain at every opporunity. Then learn C... I see later in this email you whine and moan about laziness... there is nothing stopping you from learning C but your own laziness. If you lack the time to contribute... then perhaps you should keep your mouth in check before calling the core developers lazy when they probably have similar time constraints. 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. This would probably be worse than removing the POSIX functions. POSIX and PCRE I daresay are not completely compatible. "probably" and "daresay" mean that you are just guessing. According to some people who know what they are talking about there is a one-for-one comparison between each POSIX and each PCRE function. And you are certainly guessing also. The thing about the future is that it hasn't happened yet and so one can only provide opinion to predict the unfolding of events. At least when you remove the POSIX functions then the problem space is well defined. And lots of sers will be pissed off because they won'tbe able to upgrade to PHP 6 without major programmer intervention. This is opinion. Suddenly having POSIX regex functions that are really wrappers around PCRE functions may introduce subtle differences in output for the same horde of users but without the same explicability. "may introduce"? There you go, guessng again. Can you point out *any* POSIX function that cannot be converted into PCRE? No... I leave it to you to prove the reverse since YOU want the PHP team to provide the wrappers. Don't be lazy... do
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
At 12:23 AM + 11/9/09, Tony Marston wrote: Do the maths. It's not rocket science. Tony Marston Damn, I was hoping for some rocket science. But traveling the update route isn't rocket science either. I can tell you from experience that everything changes. Nothing remains static -- so, get used to it. I've had entire languages stop overnight and all the developers had to go on to other things -- not a good experience. The deprecation of POSIX functions is minor as compared to other things. Be happy that's all you have to be concerned about. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Mon, 2009-11-09 at 15:49 +, David Otton wrote:
> 2009/11/9 Tony Marston :
>
> > Because I can't do that until I install PHP 6, but as I never play with beta
> > software waiting for it to go live will be too late.
>
> Not sure why not. If it's just the name collision, call them
> alt_ereg*() until ereg*() goes away. In fact, it's much easier to
> write unit tests against your new functions if the old functions are
> still hanging around.
>
> > I've tried looking at the PHP wiki, but I cannot see any method of
> > creating an RFC.
>
> Well, the RFCs are here, but you probably already found them:
> http://wiki.php.net/rfc (register is in the bottom-right corner).
>
> Can't help you with your php-internals problem, I'm afraid. Tried
> emailing the list manager?
>
> > I have, however, created a request in php_compat in the PEAR system at
> > http://pear.php.net/bugs/bug.php?id=16769
>
> Fair enough. Good luck.
>
And what about something like this as an internal wrapper:
if(!function_exists('ereg_*'))
{
function ereg_*()
{
}
}
And you should at least try to test the code you write for your clients
on PHP6 if that is where it is going to be hosted before servers are
upgraded, even if it's just to find out if it will break and give you
time to fix it. Hell, you could probably charge for that if the client
absolutely has to be on a PHP6 server, as something like that would fall
outside the scope of future maintenance, unless of course you wrote your
code in full knowledge of the change that would happen in PHP6.
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
2009/11/9 Tony Marston : > Because I can't do that until I install PHP 6, but as I never play with beta > software waiting for it to go live will be too late. Not sure why not. If it's just the name collision, call them alt_ereg*() until ereg*() goes away. In fact, it's much easier to write unit tests against your new functions if the old functions are still hanging around. > I've tried looking at the PHP wiki, but I cannot see any method of > creating an RFC. Well, the RFCs are here, but you probably already found them: http://wiki.php.net/rfc (register is in the bottom-right corner). Can't help you with your php-internals problem, I'm afraid. Tried emailing the list manager? > I have, however, created a request in php_compat in the PEAR system at > http://pear.php.net/bugs/bug.php?id=16769 Fair enough. Good luck. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On 11/9/09 8:56 AM, Tony Marston wrote: > I have tried subscribing to the internals list, but none of my postings ever > appears. That's unfortunate as you missed this thread: http://marc.info/?t=12553625831&r=1&w=2 Paul -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"David Otton" wrote in message news:193d27170911090331k7ecbe69cl1dd30651273e7...@mail.gmail.com... > 2009/11/9 Tony Marston : > >> So you wouldn't trust the PHP developers to write simple code which takes >> each POSIX function and redirects it to a PCRE function? I have more >> faith >> in their ability than I do yours. > > If it's as simple as you claim, why don't you mock-up your solution in > PHP, rather than C? Because I can't do that until I install PHP 6, but as I never play with beta software waiting for it to go live will be too late. > You'll get taken more seriously if you have > working code that someone can write unit tests against. > > If your solution doesn't get any traction with the core team, you'll > still be able to offer it to the community as a simple download, just > "include this at the top of your script to fix "ereg*() not found" > problems". That would be really useful to all those people whose cause > you are championing. > > (BTW, the reference implementation for PHP is... PHP. There isn't an > ISO standard or anything here. How PHP6 behaves is correct, because > it's PHP6). > > (BTW^2 - you're on the wrong list for this. If you want to influence > the guys who make the decisions you need to take this to > php-internals, where the heavyweights hang out). I have tried subscribing to the internals list, but none of my postings ever appears. I've tried looking at the PHP wiki, but I cannot see any method of creating an RFC. I have, however, created a request in php_compat in the PEAR system at http://pear.php.net/bugs/bug.php?id=16769 -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: How many hosting companies write to all their account holders to ask permission before upgrading PHP, not just from 4 to 5, but all the releases in between? Very few of them, if any, in my experience. I've no idea what horrible hosting companies you've had experiences with, however all of the companies I've used in the last few years have had an option to move back and forth between PHP4 and PHP5 in the event that certain scrips/frameworks/apps/whatever required one version over the other. What makes you think these companies won't do the same thing when they finally decide to add PHP6 to their servers? I doubt very many reputable hosting companies would simply upgrade to the latest flavor of PHP/Apache/MySQL/anything simply because it was released this morning without doing ample internal testing; if you or your clients are using one that does this - I'd advise you look elsewhere. Whenever PHP6 reaches a stable release build, it will still be quite some time before its offered as an option to any mainstream shared hosting service - this should leave you ample time to adapt to incoming changes. Failing that, you always have the option of purchasing your own server or VPS from any number of hosts to configure as you see fit. Or you can explain your moral outrage to potential clients detailing your refusal to work because you disagree with a proposed change that won't see the light of day for years to come; your call. Incessant whining under the guise of expressing your own opinion isn't going to make everything better. Sorry.
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
2009/11/9 Tony Marston : > So you wouldn't trust the PHP developers to write simple code which takes > each POSIX function and redirects it to a PCRE function? I have more faith > in their ability than I do yours. If it's as simple as you claim, why don't you mock-up your solution in PHP, rather than C? You'll get taken more seriously if you have working code that someone can write unit tests against. If your solution doesn't get any traction with the core team, you'll still be able to offer it to the community as a simple download, just "include this at the top of your script to fix "ereg*() not found" problems". That would be really useful to all those people whose cause you are championing. (BTW, the reference implementation for PHP is... PHP. There isn't an ISO standard or anything here. How PHP6 behaves is correct, because it's PHP6). (BTW^2 - you're on the wrong list for this. If you want to influence the guys who make the decisions you need to take this to php-internals, where the heavyweights hang out). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"Ashley Sheridan" wrote in message news:1257764339.1076.56.ca...@localhost... > On Mon, 2009-11-09 at 00:23 +, Tony Marston wrote: > >> developer laziness >> or incompetence is not an acceptable excuse. > > > Exactly, so fix your scripts! But my scripts aren't broken! It's PHP 6 that is broken. > I do wonder though, what hosting company you use that would just upgrade > to PHP6 without warning on you and 'break' your scripts, How many hosting companies write to all their account holders to ask permission before upgrading PHP, not just from 4 to 5, but all the releases in between? Very few of them, if any, in my experience. > yet at the same > time would not allow you to install what you call an 'amateur fudge'. I > can't think of any hosting company that would care so little about their > customers. Some hosting companies won't allow you to use htaccess files, refuse to install any optional extension, let alone one from the PECL or PEAR repositories. Some of them won't give you more than one MySQL database. Different companies provide different levels of service. The only thing that the DO have in common is that they charge you for it. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Mon, 2009-11-09 at 00:23 +, Tony Marston wrote: > developer laziness > or incompetence is not an acceptable excuse. Exactly, so fix your scripts! I do wonder though, what hosting company you use that would just upgrade to PHP6 without warning on you and 'break' your scripts, yet at the same time would not allow you to install what you call an 'amateur fudge'. I can't think of any hosting company that would care so little about their customers. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"Robert Cummings" wrote in message news:4af76e1f.2050...@interjinn.com... > Tony Marston wrote: >> "Robert Cummings" wrote in message > 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. > > Not quite true... major version moves are an opportunity to make a break > for freedom. All there needs to be is an upgrade path... and that is > clearly in play right now with the warning indicating that POSIX regex > functions are being deprecated. But a lot of people won't see those warnings until they run 5.3.0 for the first time. It is common practice, at least in all the other languages that I have used, that is something is going to be removed that it is marked as deprecated at the start of the previous release, not at the end. So marking the POIX functions as deprecated should have happened in 5.0, not 5.3. >>> 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? > > They most certainly are cruft. That is just your opinion. Other people think that PHP should be rewritten so that it appears more like their favourite language. Among the suggestions I have seen are: - make all variables statically typed instead of dynamically typed. - remove all procedural functions and make the language "pure" OO. Who decides if they are right? >.. hence the reason they are being removed. The people who decide what is, >and is not, cruft are the very same people who are writing the code. If you >are not happy with this then there's the age old saying in open source... >"put up or shut up". I can't because I don't program in C. So I shall do the nextbest thing - complain at every opporunity. >>> 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. > > This would probably be worse than removing the POSIX functions. > POSIX and PCRE I daresay are not completely compatible. "probably" and "daresay" mean that you are just guessing. According to some people who know what they are talking about there is a one-for-one comparison between each POSIX and each PCRE function. > At least when you remove the POSIX functions then the problem space is > well defined. And lots of sers will be pissed off because they won'tbe able to upgrade to PHP 6 without major programmer intervention. > Suddenly having POSIX regex functions that are really wrappers around PCRE > functions may introduce subtle differences in output for the same horde of > users but without the same explicability. "may introduce"? There you go, guessng again. Can you point out *any* POSIX function that cannot be converted into PCRE? >> 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. > > This isn't a mathematical problem. It's a question of correctness. Lot's of PHP users, myself included, do not think that it is "correct" to remove widely used functionality just beause the developers are too lazy to do a proper job. > I wasn't happy to hear POSIX regex functions were going either, but when I > heard the reasoning I did the best thing I could... I fixed my code to > p
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Sun, Nov 08, 2009 at 06:30:37PM -0500, Robert Cummings wrote: > Also, why support > two libraries for which one is obviously inferior in speed and > functionality? > Because Tony's Radicore framework has a bunch of ereg* calls in it. ;-} Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: "Robert Cummings" wrote in message 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. Not quite true... major version moves are an opportunity to make a break for freedom. All there needs to be is an upgrade path... and that is clearly in play right now with the warning indicating that POSIX regex functions are being deprecated. 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? They most certainly are cruft... hence the reason they are being removed. The people who decide what is, and is not, cruft are the very same people who are writing the code. If you are not happy with this then there's the age old saying in open source... "put up or shut up". 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. This would probably be worse than removing the POSIX functions. POSIX and PCRE I daresay are not completely compatible. At least when you remove the POSIX functions then the problem space is well defined. Suddenly having POSIX regex functions that are really wrappers around PCRE functions may introduce subtle differences in output for the same horde of users but without the same explicability. 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. This isn't a mathematical problem. It's a question of correctness. I wasn't happy to hear POSIX regex functions were going either, but when I heard the reasoning I did the best thing I could... I fixed my code to prepare for the inevitable. There's no way I'd trust my code to "just work" with POSIX functions redirected through PCRE and so I'd still need to do the same legwork. Wrapping the POSIX regex functions around PCRE will lead to more problems than it solves IMHO. 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"Robert Cummings" wrote in message news:4af7549d.1060...@interjinn.com... > Tony Marston wrote: >> "Eddie Drapkin" wrote in message >> news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com... >> On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston >> 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" wrote in message >>> news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston 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" wrote in message > news:4af70120.1040...@network-technologies.org... >> 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 ht
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
Tony Marston wrote: "Eddie Drapkin" wrote in message news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com... On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston 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" wrote in message news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston 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" wrote in message news:4af70120.1040...@network-technologies.org... 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*. You don't think PHP should support legacy cruft in the core forever do you? 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? 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"Eddie Drapkin" wrote in message news:68de37340911081330v799803f3he6ed60ecc6e67...@mail.gmail.com... On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston 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" wrote in message > news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... >> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston >> 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" wrote in message >>> news:4af70120.1040...@network-technologies.org... 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. > You talk about a "professional" fix. The right fix is to remove the > depracated elements My whole argument is that they shouldn't have been deprecated in the first place. > from your scripts before upgrading PHP, which > realistically shouldn't be that big of a deal for the vast majority of > expressions. It is going to be a VERY big deal for all hose users who suddenly finf that their scripts won't run in PHP 6. > Rather than accept the change and just fix your scripts, It's not a change, it's a removal of core functions that have worked flawlessly for years. Both the POSIX and the PCRE functions needed to be updated to work with unicode, but the developers couldn't be bothered to update both. The only reason that the POSIX have been deprecated is because the PHP developers are either too lazy or too incompetent to provide a proper fix. > you propose a problem that breaks a lot of other things and introduces > way more problems than it solves. > You're not the first person to post this exact same tantrum on this l> list and the response has always been: fix your scripts The scripts aren't broken, it's PHP 6 that's broken. > or don't upgrade. Not an acceptable option. > Seeing as PHP 6 is a long ways away you've got plenty of > time to fix your scripts Just as the PHP developers have plenty of time to do a proper job. > and it's not like this is being sprung overnight, To a lot of peope it will appear to be sprung overnight as the first time they will know that the POSIX functions have been removed is when their scripts don't work. > so do the real professional thing The professional thing would be to fix PHP 6 so that is doesn't break existing scripts needlessly. > and upgrade your scripts, > if you want to upgrade (when 6 is released). Breaking BC happens. There is a difference between breaking BC because of genuinely insurmountable reasons, and breaking it because of pure laziness. -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Sun, Nov 8, 2009 at 4:13 PM, Tony Marston 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" wrote in message > news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... >> On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston >> 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" wrote in message >>> news:4af70120.1040...@network-technologies.org... 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. 2) Pick a different hosting provider. 3) Fix your scripts. You talk about a "professional" fix. The right fix is to remove the depracated elements from your scripts before upgrading PHP, which realistically shouldn't be that big of a deal for the vast majority of expressions. Rather than accept the change and just fix your scripts, you propose a problem that breaks a lot of other things and introduces way more problems than it solves. You're not the first person to post this exact same tantrum on this list and the response has always been: fix your scripts or don't upgrade. Seeing as PHP 6 is a long ways away you've got plenty of time to fix your scripts and it's not like this is being sprung overnight, so do the real professional thing and upgrade your scripts, if you want to upgrade (when 6 is released). Breaking BC happens. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
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" wrote in message news:68de37340911081209p45577d46r70a3c194f1079...@mail.gmail.com... > On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston > 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" wrote in message >> news:4af70120.1040...@network-technologies.org... >>> 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
On Sun, Nov 8, 2009 at 2:47 PM, Tony Marston 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" wrote in message > news:4af70120.1040...@network-technologies.org... >> 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
"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" wrote in message news:4af70120.1040...@network-technologies.org... > 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
Re: [PHP] Convert deprecated POSIX functions into wrappers for equivalent PCRE functions
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
