Hi geeks!
We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?
Regards,
Philip
is it not emulated using pcre now? as in, the ereg library is not used anymore
Hi geeks!
We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?
Regards,
Philip--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hello Pierre,
I mean that the ereg extension is deprecated, yet we cannot disable
it while compiling PHP. In other words, ereg() and friends always
exist in PHP, and emit E_DEPRECATED errors upon use. We should have
the option of creating fatal undefined function errors… basically.
Currently this exists for ereg:
--with-regex[=TYPE]
So I guess we want:
--without-regex
Even though --disable-ereg would feel more natural.
Regards,
Philip
is it not emulated using pcre now? as in, the ereg library is not used anymore
Hi geeks!
We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?
Regards,
Philip--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
what I mean is that, as far as I remember, the deprecation is only an
information via the documentation. We did not want to break BC and all
that as it is now emulated through pcre.
Hello Pierre,
I mean that the ereg extension is deprecated, yet we cannot disable
it while compiling PHP. In other words, ereg() and friends always
exist in PHP, and emitE_DEPRECATEDerrors upon use. We should have
the option of creating fatal undefined function errors… basically.Currently this exists for ereg:
--with-regex[=TYPE]
So I guess we want:
--without-regex
Even though --disable-ereg would feel more natural.
Regards,
Philipis it not emulated using pcre now? as in, the ereg library is not used anymore
Hi geeks!
We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?
Regards,
Philip--
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
what I mean is that, as far as I remember, the deprecation is only an
information via the documentation. We did not want to break BC and all
that as it is now emulated through pcre.
no, we deprecated it, and albeit it was a discussion to un-deprecate it, we
kept it:
I think we have enough reasons to keep it deprecated as we have much better
alternative (pcre) which we want to recommend to the users.
http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Can you please carefully read what I wrote? Thanks.
I said:
" the deprecation is only an information via the documentation"
as in not adding noises to the language without any good reason.
what I mean is that, as far as I remember, the deprecation is only an
information via the documentation. We did not want to break BC and all
that as it is now emulated through pcre.no, we deprecated it, and albeit it was a discussion to un-deprecate it, we
kept it:
I think we have enough reasons to keep it deprecated as we have much better
alternative (pcre) which we want to recommend to the users.
http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
This thread has veered off-course. So to summarize:
(1) ereg is deprecated, and usage is discouraged
(2) It emits E_DEPRECATED errors as of PHP 5.3
(3) We cannot disable/remove ereg at compile time (today)
I'm suggesting we alter (3) so that we, the people who compile
PHP, can optionally remove this extension from our PHP 5.4+.
This means adding --without-regex to go along with --with-regex,
which is the current compile-time option for ext/ereg.
Any objections? Regardless of deprecation status, this option
should be available. Or if not, why?
Regards,
Philip
Can you please carefully read what I wrote? Thanks.
I said:
" the deprecation is only an information via the documentation"
as in not adding noises to the language without any good reason.
what I mean is that, as far as I remember, the deprecation is only an
information via the documentation. We did not want to break BC and all
that as it is now emulated through pcre.no, we deprecated it, and albeit it was a discussion to un-deprecate it, we
kept it:
I think we have enough reasons to keep it deprecated as we have much better
alternative (pcre) which we want to recommend to the users.
http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54--
Ferenc Kovács
@Tyr43l - http://tyrael.hu--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
(1) ereg is deprecated, and usage is discouraged
(2) It emitsE_DEPRECATEDerrors as of PHP 5.3
(3) We cannot disable/remove ereg at compile time (today)I'm suggesting we alter (3) so that we, the people who compile
PHP, can optionally remove this extension from our PHP 5.4+.
OK, propose a patch :) Note that pgsql seems to be using regex, and may
be other modules, so it should be made to use PCRE instead I guess.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Any objections? Regardless of deprecation status, this option
should be available. Or if not, why?
The main reason is that we are not done removing all the dependencies.
This is a large deprecation that is going to require the process to span
multiple versions. We could add a way to disable it, but it is going to
break some extensions in ways that are not obvious to the user.
-Rasmus
Any objections? Regardless of deprecation status, this option
should be available. Or if not, why?The main reason is that we are not done removing all the dependencies.
This is a large deprecation that is going to require the process to span
multiple versions. We could add a way to disable it, but it is going to
break some extensions in ways that are not obvious to the user.
Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like
the wise choice, and adding --without-regex then as well.
Regards,
Philip
We can only do it for a 6.x, not for a 5.5. So I would not do it too
early in the process.
Any objections? Regardless of deprecation status, this option
should be available. Or if not, why?The main reason is that we are not done removing all the dependencies.
This is a large deprecation that is going to require the process to span
multiple versions. We could add a way to disable it, but it is going to
break some extensions in ways that are not obvious to the user.Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like
the wise choice, and adding --without-regex then as well.Regards,
Philip
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
bump
anybody working on this so that we can remove the ereg "dependency" for 5.5?
would be nice if we could open an issue for this with the necessary info to
anybody to jump into fixing it.
Any objections? Regardless of deprecation status, this option
should be available. Or if not, why?The main reason is that we are not done removing all the dependencies.
This is a large deprecation that is going to require the process to span
multiple versions. We could add a way to disable it, but it is going to
break some extensions in ways that are not obvious to the user.Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like
the wise choice, and adding --without-regex then as well.Regards,
Philip
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
(3) We cannot disable/remove ereg at compile time (today)
I'm suggesting we alter (3) so that we, the people who compile
PHP, can optionally remove this extension from our PHP 5.4+.
For what it's worth, I was able to successfully remove ereg from PHP 5.3
(.6, I think; this was a while ago) by just removing ext/ereg from the
source tree before running configure (same with reflection and spl).
I presume though that this only worked because I happened to disable all
extensions that depended on ereg at the same time. Even so, an option
would be useful even if it was accompanied by a warning saying that it
might break the build depending on other extension choices.
--
Oleg
what I mean is that, as far as I remember, the deprecation is only an
information via the documentation. We did not want to break BC and all
that as it is now emulated through pcre.
There is no emulation, the behavior of the ereg library and pcre is
different that emulation is not possible in a useful way. It is also not
only in documentation but by throwing E_DEPRECATED.
Currently this exists for ereg:
--with-regex[=TYPE]
So I guess we want:
--without-regex
Even though --disable-ereg would feel more natural.
--disable is the counterpart to --enable as generated by autoconf.
--without the counterpart to --with. We use --with for things using some
library. ereg uses by default a bundled library but could also be
configured to use a system configured library. Therefor "--with" is
correct, therefore --without is the "correct" consequence.
We're unable to disable the ereg extension today, yet it's been
deprecated since PHP 5.3.0. Is this by design?
It's at least partly by design. We had some code using ereg library
stuff internally, so core PHP depended on it. The plan was to rewrite
these code parts to use pcre. I'm not sure that has been done, yet. Till
then we can't make ereg optional.
We should look into this for 5.5, using ereg is a bit dangerous (0-byte
safety etc.) so dropping it is a good thing, even aside from reducing
the amount of code to maintain.
johannes