Re: [PHP-DEV] Kill ereg with fire
On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts? Afair we have a patch floating around, but never made it into the repo, but everybody seemed to agree to remove the core dependency of ereg and make it optional to enable. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Kill ereg with fire
Hi Ferenc, On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts? Afair we have a patch floating around, but never made it into the repo, but everybody seemed to agree to remove the core dependency of ereg and make it optional to enable. You mean make it optional to install via PECL, right? I agree ;-) Package maintainers can always choose to ship their php packages with ereg as a means to keep supporting it, regardless of how it’s provided (bundled or PECL). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Kill ereg with fire
+1 Kill it with fire and throw more gasoline ontop of the fire. On Sun, Aug 31, 2014 at 8:08 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi Ferenc, On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts? Afair we have a patch floating around, but never made it into the repo, but everybody seemed to agree to remove the core dependency of ereg and make it optional to enable. You mean make it optional to install via PECL, right? I agree ;-) Package maintainers can always choose to ship their php packages with ereg as a means to keep supporting it, regardless of how it’s provided (bundled or PECL). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Kill ereg with fire
Heck... No :) Or we mark it as dead right away, single release for the sake of it and let it die. On Aug 31, 2014 2:08 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi Ferenc, On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts? Afair we have a patch floating around, but never made it into the repo, but everybody seemed to agree to remove the core dependency of ereg and make it optional to enable. You mean make it optional to install via PECL, right? I agree ;-) Package maintainers can always choose to ship their php packages with ereg as a means to keep supporting it, regardless of how it’s provided (bundled or PECL). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Kill ereg with fire
On Sun, Aug 31, 2014 at 8:32 AM, Pierre Joye pierre@gmail.com wrote: Heck... No :) Or we mark it as dead right away, single release for the sake of it and let it die. I think a single, unmaintained release of ext/ereg in PECL would be acceptable, but I don't really see the point of that either. If you still rely on ereg you probably can't upgrade from an earlier version of PHP so you'll end up using an old release which already has ereg. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Kill ereg with fire
I have on occasion come across code that uses split(), more often than not as if it were explode() with a literal delimiter. If ereg is to be removed (for which I am +1) does anyone have any objections to making split() into an alias of explode()? This would also be consistent with the join() - implode() alias. Ps. Sorry for top reply, my phone doesn't seem to want to play nice with an in line response. On 31 Aug 2014 17:29, Levi Morrison le...@php.net wrote: On Sun, Aug 31, 2014 at 8:32 AM, Pierre Joye pierre@gmail.com wrote: Heck... No :) Or we mark it as dead right away, single release for the sake of it and let it die. I think a single, unmaintained release of ext/ereg in PECL would be acceptable, but I don't really see the point of that either. If you still rely on ereg you probably can't upgrade from an earlier version of PHP so you'll end up using an old release which already has ereg. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Kill ereg with fire
On 31 Aug 2014, at 20:34, Chris Wright c...@daverandom.com wrote: I have on occasion come across code that uses split(), more often than not as if it were explode() with a literal delimiter. If ereg is to be removed (for which I am +1) does anyone have any objections to making split() into an alias of explode()? This would also be consistent with the join() - implode() alias. The big disadvantage to that would be, that those people who use more advanced features will have a much harder time to figure out what went wrong. I think this is better left alone. Best regards Rouven -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Kill ereg with fire
On Sun, Aug 31, 2014 at 2:08 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi Ferenc, On 31 Aug, 2014, at 7:00 pm, Ferenc Kovacs tyr...@gmail.com wrote: On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts? Afair we have a patch floating around, but never made it into the repo, but everybody seemed to agree to remove the core dependency of ereg and make it optional to enable. You mean make it optional to install via PECL, right? I agree ;-) imo that's a different topic (removing build dependency on ereg and moving it to pecl) but as we are deprecating the ereg functions in the userland for a while now (since 5.3) I would be fine with it in PHP 7. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Kill ereg with fire
Hi internals (again), Recently I’ve done a small assessment on how feasible it is to remove ext/ereg from the project for the next major version. This is the result (so far): https://github.com/datibbaw/php-src/compare/kill-ereg I’ve replaced two instances of ereg with their pcre equivalents, OPcache and PGSQL. Btw, simply using ‘pcreposix.h’ didn’t work out for OPcache, I would get this error: Error Blacklist compilation: invalid argument to regex routine Perhaps I’ve missed something obvious, but porting it wasn’t hard either. Thoughts?
