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?
On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meesters@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
Hi Ferenc,
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
+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.meesters@gmail.com
wrote:
Hi Ferenc,
On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters <
tjerk.meesters@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
Heck... No :)
Or we mark it as dead right away, single release for the sake of it and let
it die.
Hi Ferenc,
On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters <
tjerk.meesters@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
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.
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.
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.
I have on occasion come across code that uses split(), more often than not
as if it wereexplode()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 ofexplode()? This would also be
consistent with thejoin()->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
On Sun, Aug 31, 2014 at 2:08 PM, Tjerk Meesters tjerk.meesters@gmail.com
wrote:
Hi Ferenc,
On Sun, Aug 31, 2014 at 7:08 AM, Tjerk Meesters tjerk.meesters@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