Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Deprecations for PHP 7.2 »

[RFC] Deprecations for PHP 7.2

php.internals

Nikita Popov

9 years ago
Hi internals! I've submitted this RFC for PHP 7.1 previously, but didn't follow through due to time constraints. Now I'd like to propose an extended version for PHP 7.2 and vote on it sooner rather than later to avoid a repeat performance. https://wiki.php.net/rfc/deprecations_php_7_2 The RFC combines a number of deprecation and removal proposals. Each one will get a separate 2/3 majority vote. The RFC overlaps with some recently discussed topics (each, binary strings) -- I'm fine with dropping these if someone has a more specific RFC. I expect some of these are no-brainers, while others are more controversial -- please share your specific concerns. Thanks, Nikita

Christoph Becker

9 years ago
On 18.11.2016 at 15:55, Nikita Popov wrote:
> Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC. > > I expect some of these are no-brainers, while others are more controversial > -- please share your specific concerns.
Thanks, Nikita! I'm generally in favor of such clean up. The only exception would be features which have only been available as of PHP 7, currently only assertion expressions. Deprecating assertion strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2 compatible code, even though 7.2 GA is supposed to be released in December 2017, whereas there'll be security support for 5.6 until end of 2018[1]. [1] <http://php.net/supported-versions.php>
-- Christoph M. Becker

Nikita Popov

9 years ago
On Fri, Nov 18, 2016 at 6:45 PM, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 18.11.2016 at 15:55, Nikita Popov wrote: > > Hi internals! > > > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > > due to time constraints. Now I'd like to propose an extended version for > > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > > performance. > > > > https://wiki.php.net/rfc/deprecations_php_7_2 > > > > The RFC combines a number of deprecation and removal proposals. Each one > > will get a separate 2/3 majority vote. The RFC overlaps with some > recently > > discussed topics (each, binary strings) -- I'm fine with dropping these > if > > someone has a more specific RFC. > > > > I expect some of these are no-brainers, while others are more > controversial > > -- please share your specific concerns. > > Thanks, Nikita! I'm generally in favor of such clean up. > > The only exception would be features which have only been available as > of PHP 7, currently only assertion expressions. Deprecating assertion > strings as of PHP 7.2 would make it hard to provide PHP 5.6 and PHP 7.2 > compatible code, even though 7.2 GA is supposed to be released in > December 2017, whereas there'll be security support for 5.6 until end of > 2018[1]. > > [1] <http://php.net/supported-versions.php> >
This is a reasonable concern. My opinion on assert() and PHP 5 vs PHP 7 is basically this: You can use assert() the same way in PHP 5 as you do in PHP 7. Assertion expressions *are* supported in PHP 5. The only difference is that it's not zero-cost and error reporting is slightly worse. And well, PHP 5 being slower than PHP 7 is kinda the case whether you use assertions or not. If you use PHP 5, performance is clearly your primary concern. Thanks, Nikita

Kalle Sommer Nielsen

9 years ago
Hi Nikita 2016-11-18 15:55 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>:
> Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC. > > I expect some of these are no-brainers, while others are more controversial > -- please share your specific concerns.
Awesome list, thanks for your work. I got a couple of things to maybe consider adding: arg_separator.output/input -- Do we really need an ini to define these, can't they be baked in or something? (I did not look at the code) auto_prepend/auto_append_file directives, I would be amazed if there couldn't be some optimization complications with those too register_argv_argc -- deprecate for non CLI? Might have other things to add later on, these are just what I had in mind so far
-- regards, Kalle Sommer Nielsen kalle@php.net

Christoph Becker

9 years ago
On 18.11.2016 at 20:01, Kalle Sommer Nielsen wrote:
> 2016-11-18 15:55 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>: > >> I've submitted this RFC for PHP 7.1 previously, but didn't follow through >> due to time constraints. Now I'd like to propose an extended version for >> PHP 7.2 and vote on it sooner rather than later to avoid a repeat >> performance. >> >> https://wiki.php.net/rfc/deprecations_php_7_2 >> >> The RFC combines a number of deprecation and removal proposals. Each one >> will get a separate 2/3 majority vote. The RFC overlaps with some recently >> discussed topics (each, binary strings) -- I'm fine with dropping these if >> someone has a more specific RFC. >> >> I expect some of these are no-brainers, while others are more controversial >> -- please share your specific concerns. > > Awesome list, thanks for your work. I got a couple of things to maybe > consider adding: > > arg_separator.output/input -- Do we really need an ini to define > these, can't they be baked in or something? (I did not look at the > code)
See also a recent discussion on comp.lang.php: <https://groups.google.com/forum/#!topic/comp.lang.php/wHi0skD_gTc>. TL;DR: these ini settings may cause quite some confusion (note that the OP is a long-term PHP developer), but removing them might cause considerable BC breakage. We have to be very careful here, IMHO.
-- Christoph M. Becker

Yasuo Ohgaki

9 years ago
Hi all, On Sat, Nov 19, 2016 at 4:01 AM, Kalle Sommer Nielsen <kalle@php.net> wrote:
> auto_prepend/auto_append_file directives
auto_prepend/append_file is handy to check application performance/statistical information such as memory usage while development and/or testing, for example. Do these harm any other than shooting their own foot? Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Kalle Sommer Nielsen

9 years ago
2016-11-19 1:05 GMT+01:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:
> Hi all, > > On Sat, Nov 19, 2016 at 4:01 AM, Kalle Sommer Nielsen <kalle@php.net> wrote: >> auto_prepend/auto_append_file directives > > auto_prepend/append_file is handy to check application > performance/statistical information such as memory usage while > development and/or testing, for example. Do these harm any other than > shooting their own foot? >
Maybe not so much, but I'd like to hear any impact they could have on optimization much like some of the features in the RFC is mentioned to be problematic. I did used to use those directives for similar things, but it was a decade ago :/
-- regards, Kalle Sommer Nielsen kalle@php.net

Jan Ehrhardt

9 years ago
Nikita Popov in php.internals (Fri, 18 Nov 2016 15:55:23 +0100):
> https://wiki.php.net/rfc/deprecations_php_7_2 > >The RFC combines a number of deprecation and removal proposals. Each one >will get a separate 2/3 majority vote. The RFC overlaps with some recently >discussed topics (each, binary strings)
I must have missed the discussion about each(). And this really surprised me:
> The each() function is inferior to foreach in pretty much every > imaginable way, including being more than 10 times slower.
But it is mentioned in a 9-year old comment in the manual: https://php.net/manual/en/function.each.php#75692 A quick grep in my Drupal7 source code showed that not everybody is aware of that. For instance, even the views module use a list() = each() construction: http://cgit.drupalcode.org/views/tree/includes/view.inc#n1740 This means that at least 800,000 sites use list() = each() at the moment. I am fine with deprecation, but this may be more wide spread than one might assume.
-- Jan

Tony Marston

9 years ago
"Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com...
> >Hi internals! > >I've submitted this RFC for PHP 7.1 previously, but didn't follow through >due to time constraints. Now I'd like to propose an extended version for >PHP 7.2 and vote on it sooner rather than later to avoid a repeat >performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > >The RFC combines a number of deprecation and removal proposals. Each one >will get a separate 2/3 majority vote. The RFC overlaps with some recently >discussed topics (each, binary strings) -- I'm fine with dropping these if >someone has a more specific RFC. > >I expect some of these are no-brainers, while others are more controversial >-- please share your specific concerns. > >Thanks, >Nikita
I am against the removal of the $errorcontext argument of error handler as this has been a valuable part of my error handler for over ten years. Whenever trigger_error() is called with a fatal error I write all available details to a log file as well as sending an email. In order to obtain additional data I use errorcontext to determine the following: a) Was it called from a function or an object? For this I use code such as the following: if (isset($errcontext['this']) AND is_object($errcontext['this'])) { b) If it was called from an object, was it one of my database objects? If yes, then obtain some extra information using code such as the following: // retrieve error details from DML object if (method_exists($errcontext['this'], 'getQuery')) { $query = $errcontext['this']->getQuery(); } // if if (method_exists($errcontext['this'], 'getErrorNo')) { $errno = $errcontext['this']->getErrorNo(); } // if if (method_exists($errcontext['this'], 'getErrorString')) { $errstr = $errcontext['this']->getErrorString(); } // if if (method_exists($errcontext['this'], 'getErrorString2')) { $errstr2 = $errcontext['this']->getErrorString2(); } // if Saying that I should stop using $errorcontext and instead use a debugger is very short sighted. I *NEED* to have this data available in the error log as soon as the error happens. In several cases I cannot use a debugger as my application is running behind a client's firewall and their security restrictions forbid the use of a debugger from outside of that firewall. I notice that the reason for this recommendation is "because the $errcontext can be used to modify all references and objects in the current scope." If this is the case then why not make $errorcontext read-only so that nothing can be changed. I can imagine lots of people reading from $errorcontext, but how many actually write? I certainly don't.
-- Tony Marston

Nikita Popov

9 years ago
On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er= > G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com... > > >> Hi internals! >> >> I've submitted this RFC for PHP 7.1 previously, but didn't follow through >> due to time constraints. Now I'd like to propose an extended version for >> PHP 7.2 and vote on it sooner rather than later to avoid a repeat >> performance. >> >> https://wiki.php.net/rfc/deprecations_php_7_2 >> >> The RFC combines a number of deprecation and removal proposals. Each one >> will get a separate 2/3 majority vote. The RFC overlaps with some recently >> discussed topics (each, binary strings) -- I'm fine with dropping these if >> someone has a more specific RFC. >> >> I expect some of these are no-brainers, while others are more >> controversial >> -- please share your specific concerns. >> >> Thanks, >> Nikita >> > > I am against the removal of the $errorcontext argument of error handler as > this has been a valuable part of my error handler for over ten years. > Whenever trigger_error() is called with a fatal error I write all available > details to a log file as well as sending an email. In order to obtain > additional data I use errorcontext to determine the following: > > a) Was it called from a function or an object? For this I use code such as > the following: > > if (isset($errcontext['this']) AND is_object($errcontext['this'])) { > > b) If it was called from an object, was it one of my database objects? If > yes, then obtain some extra information using code such as the following: > > // retrieve error details from DML object > if (method_exists($errcontext['this'], 'getQuery')) { > $query = $errcontext['this']->getQuery(); > } // if > if (method_exists($errcontext['this'], 'getErrorNo')) { > $errno = $errcontext['this']->getErrorNo(); > } // if > if (method_exists($errcontext['this'], 'getErrorString')) { > $errstr = $errcontext['this']->getErrorString(); > } // if > if (method_exists($errcontext['this'], 'getErrorString2')) { > $errstr2 = $errcontext['this']->getErrorString2(); > } // if >
I'm afraid you're out of luck here :/ This usage will no longer be possible as of PHP 7.1 -- independently of the deprecation proposed in this RFC. See: https://3v4l.org/sQBL9 Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be more precise, whenever $this was used as a CV, rather than implicit UNUSED operand). As of PHP 7.1 $this is never included in the symbol table. This change is due to https://wiki.php.net/rfc/this_var. But! This functionality is still available through debug_backtrace(). That's the correct way of fetching the $this of a parent frame, which should always work (rather than *sometimes* on PHP < 7.1), and is independent of the error handling mechanism. So, to clarify: Is $this the only thing from the error context you're interested in? Or do you also use all the other variables?
> Saying that I should stop using $errorcontext and instead use a debugger > is very short sighted. I *NEED* to have this data available in the error > log as soon as the error happens. In several cases I cannot use a debugger > as my application is running behind a client's firewall and their security > restrictions forbid the use of a debugger from outside of that firewall.
> I notice that the reason for this recommendation is "because the > $errcontext can be used to modify all references and objects in the current > scope." If this is the case then why not make $errorcontext read-only so > that nothing can be changed. I can imagine lots of people reading from > $errorcontext, but how many actually write? I certainly don't.
We can do this for references (i.e., dereference them for the provided symbol table), but not for objects, because we don't have any way of enforcing immutability on the language side. Thanks, Nikita

Tony Marston

9 years ago
"Nikita Popov" wrote in message news:CAF+90c91SPFOHiTJGpwTEvZt_Wyk+hTX4-TANTMsshhcTQQVfw@mail.gmail.com...
> >On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston <TonyMarston@hotmail.com> >wrote: > >> "Nikita Popov" wrote in message news:CAF+90c8Wox0wadAVPsP83er= >> G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com... >> >> >>> Hi internals! >>> >>> I've submitted this RFC for PHP 7.1 previously, but didn't follow >>> through >>> due to time constraints. Now I'd like to propose an extended version for >>> PHP 7.2 and vote on it sooner rather than later to avoid a repeat >>> performance. >>> >>> https://wiki.php.net/rfc/deprecations_php_7_2 >>> >>> The RFC combines a number of deprecation and removal proposals. Each one >>> will get a separate 2/3 majority vote. The RFC overlaps with some >>> recently >>> discussed topics (each, binary strings) -- I'm fine with dropping these >>> if >>> someone has a more specific RFC. >>> >>> I expect some of these are no-brainers, while others are more >>> controversial >>> -- please share your specific concerns. >>> >>> Thanks, >>> Nikita >>> >> >> I am against the removal of the $errorcontext argument of error handler >> as >> this has been a valuable part of my error handler for over ten years. >> Whenever trigger_error() is called with a fatal error I write all >> available >> details to a log file as well as sending an email. In order to obtain >> additional data I use errorcontext to determine the following: >> >> a) Was it called from a function or an object? For this I use code such >> as >> the following: >> >> if (isset($errcontext['this']) AND is_object($errcontext['this'])) { >> >> b) If it was called from an object, was it one of my database objects? If >> yes, then obtain some extra information using code such as the following: >> >> // retrieve error details from DML object >> if (method_exists($errcontext['this'], 'getQuery')) { >> $query = $errcontext['this']->getQuery(); >> } // if >> if (method_exists($errcontext['this'], 'getErrorNo')) { >> $errno = $errcontext['this']->getErrorNo(); >> } // if >> if (method_exists($errcontext['this'], 'getErrorString')) { >> $errstr = $errcontext['this']->getErrorString(); >> } // if >> if (method_exists($errcontext['this'], 'getErrorString2')) { >> $errstr2 = $errcontext['this']->getErrorString2(); >> } // if >> > >I'm afraid you're out of luck here :/ This usage will no longer be possible >as of PHP 7.1 -- independently of the deprecation proposed in this RFC. >See: https://3v4l.org/sQBL9 > >Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be >more precise, whenever $this was used as a CV, rather than implicit UNUSED >operand). As of PHP 7.1 $this is never included in the symbol table. This >change is due to https://wiki.php.net/rfc/this_var. > >But! This functionality is still available through debug_backtrace(). >That's the correct way of fetching the $this of a parent frame, which >should always work (rather than *sometimes* on PHP < 7.1), and is >independent of the error handling mechanism.
The RFC does not specify this, it simply says "use a proper debugger". Will I still be able to use debug_backtrace() to obtain the same information that is available in $errorcontext?If so, this should be explicitly stated in the RFC.
>So, to clarify: Is $this the only thing from the error context you're >interested in? Or do you also use all the other variables?
I use all the other variables as well, but sometimes I need to use $errorcontext to supply additional information
-- Tony Marston

Rowan Collins

9 years ago
On 18/11/2016 14:55, Nikita Popov wrote:
> Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 >
Hi Nikita, I'm interested to see create_function() on this list, as one of my first contributions to the list was suggesting its deprecation, and I didn't feel there was sufficient consensus to go forward. Thread here: http://marc.info/?t=138178649200002&r=2&w=2 http://marc.info/?t=138178649200002&r=1&w=2 It's possible the intervening three years have changed things sufficiently to reconsider, though. On a broader note, I would like to restate my desire for some kind of road map or plan of roughly when 8.0 is expected, to inform decisions on things like this. Does "deprecate in 7.2" mean removal in 2 years time, or 5, or 10? Previously I've been answered with "the Big Feature of 8.0 will be JIT", but I am not a fan of tying the deprecation and feature policy to "whenever we happen to have a rewrite of the engine ready"; it muddles product branding with API versioning. If JIT isn't ready for 10 years, does that mean we have to wait 10 years to break BC? And if it's ready in 2018, does that mean everything deprecated in 7.2 has to be immediately dropped after just one year? Should we decouple the Zend Engine version from the language version, and use separate semantic versions for each? Regards,
-- Rowan Collins [IMSoP]

Kalle Sommer Nielsen

9 years ago
Hi Rowan 2016-11-19 18:23 GMT+01:00 Rowan Collins <rowan.collins@gmail.com>:
> On a broader note, I would like to restate my desire for some kind of road > map or plan of roughly when 8.0 is expected, to inform decisions on things > like this. Does "deprecate in 7.2" mean removal in 2 years time, or 5, or > 10? > > Previously I've been answered with "the Big Feature of 8.0 will be JIT", but > I am not a fan of tying the deprecation and feature policy to "whenever we > happen to have a rewrite of the engine ready"; it muddles product branding > with API versioning. If JIT isn't ready for 10 years, does that mean we have > to wait 10 years to break BC? And if it's ready in 2018, does that mean > everything deprecated in 7.2 has to be immediately dropped after just one > year? Should we decouple the Zend Engine version from the language version, > and use separate semantic versions for each?
I kinda liked the model we had back in the late 5.x series (namely starting with 5.3 from 2009), although that was before we had a release plan decided, it did make a lot of sense to deprecate some features, of course taking into consideration what they are and the impact they have. The model we had was deprecate in x.z, then remove in z+1, things to this list include safe_mode, register_globals for example, not that these were as ground breaking changes because of the movement to use PHP5. I think create_function(), as mentioned, is a feature worthy of being deprecated in one version, then removed in the next. Like you also mention, major versions are really rare and I think it should be kept that way, or at least until we reach a point where we literally cannot improve PHP7 anymore without major changes, such as the case for PHP 5.6 was. Side note, I still think that with the amount of work, changes and features, PHP 5.3 was almost worth the role of being a major version, but lets not side track the subject ;-) With our current model, that means that when we deprecate something, users got a year to upgrade their code, if they are bleeding edge users, but most are likely not, so they have more time to upgrade the code, and to be fair, we try to do the removals in moderate parts to not overwhelm developers who are upgrading their code, or projects that supports a wide range of PHP versions, such as phpB which support PHP 5.3.0+. After that 1 year, we do offer 2 years additional security fixes support, so I think that there is more than enough time for our community to update their code bases. PHP 7.0 was a great success externally for migration. So to answer your question in a short without much more rambling: I think we should deprecate in x.z, then remove in x.z+1 depending on the feature, if we say "Oh let's remove this in the next major", chances are that major won't even be branches for years, and at that time, it could be forgotten.
-- regards, Kalle Sommer Nielsen kalle@php.net

Marco Pivetta

9 years ago
On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen <kalle@php.net> wrote:
> So to answer your question in a short without much more rambling: I > think we should deprecate in x.z, then remove in x.z+1 depending on > the feature, if we say "Oh let's remove this in the next major", > chances are that major won't even be branches for years, and at that > time, it could be forgotten. >
That will end up breaking the "expected" (because it's not that way anyway, but almost) SemVer approach, diminishing the trust from consumers in any kind of upgrade. Most of the current open-source libs out there are trying to push for SemVer - having PHP not following that seems like a huge mess to me. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

Christoph Becker

9 years ago
On 19.11.2016 at 18:56, Marco Pivetta wrote:
> On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen <kalle@php.net> wrote: > >> So to answer your question in a short without much more rambling: I >> think we should deprecate in x.z, then remove in x.z+1 depending on >> the feature, if we say "Oh let's remove this in the next major", >> chances are that major won't even be branches for years, and at that >> time, it could be forgotten. > > That will end up breaking the "expected" (because it's not that way anyway, > but almost) SemVer approach, diminishing the trust from consumers in any > kind of upgrade. > Most of the current open-source libs out there are trying to push for > SemVer - having PHP not following that seems like a huge mess to me.
Our release process[1] explicitly forbids breaking userland API between x.y.z and x.y+1.z. [1] <https://wiki.php.net/rfc/releaseprocess>
-- Christoph M. Becker

Kalle Sommer Nielsen

9 years ago
Hi Marco 2016-11-19 18:56 GMT+01:00 Marco Pivetta <ocramius@gmail.com>:
> That will end up breaking the "expected" (because it's not that way anyway, > but almost) SemVer approach, diminishing the trust from consumers in any > kind of upgrade. > Most of the current open-source libs out there are trying to push for SemVer > - having PHP not following that seems like a huge mess to me.
I don't think a SemVer approach will work for PHP in its current state, not to say that it won't but the way that some of these things are implemented, it makes complications for further internal improvements that comes with each major/minor release. Take the "Forbid Dynamic Scope Introspection" RFC you voted yes to, which is implemented in PHP 7.1, sure, this one in particular is on the path down to pandora's PHP edge case box, but without it we would have lost speed gain optimizations (faster PHP by upgrading) and have to stick around with code that could lead to pitfalls, hard to debug code or nasty crashes. I do understand that we have to draw a line in what is sensible to deprecate and remove in favor of what and when, but keep in mind how large a userbase PHP serves, hundreds of millions of websites, millions of developers and yet we are maybe about 20 active developers who contribute code to PHP's internals on a regular basis. Time, resources and energy for keeping things in closed state for so long where we cannot change anything is not fun or motivating for contributing. (And I would rather not that PHP felt into a version scheme similar to that of Chrome where in December we could have PHP 42.0.) [1] https://wiki.php.net/rfc/forbid_dynamic_scope_introspection
-- regards, Kalle Sommer Nielsen kalle@php.net

Rowan Collins

9 years ago
On 19/11/2016 17:56, Marco Pivetta wrote:
> On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen <kalle@php.net > <mailto:kalle@php.net>> wrote: > > So to answer your question in a short without much more rambling: I > think we should deprecate in x.z, then remove in x.z+1 depending on > the feature, if we say "Oh let's remove this in the next major", > chances are that major won't even be branches for years, and at that > time, it could be forgotten. > > > That will end up breaking the "expected" (because it's not that way > anyway, but almost) SemVer approach, diminishing the trust from > consumers in any kind of upgrade. > Most of the current open-source libs out there are trying to push for > SemVer - having PHP not following that seems like a huge mess to me. >
I agree with this, to an extent. If we formally disavow any meaning of "major release" other than branding, the expectation is less of an issue in itself. But it's interesting that PostgreSQL is moving to a 2-part version numbering: instead of the annual feature releases being 9.7.0, 9.8.0, 9.9.0 etc, they will be 10.0, 11.0, 12.0, thus eliminating debate about which releases should be classed as "major".
> Like you also mention, major versions are really rare and I > think it should be kept that way, or at least until we reach a point > where we literally cannot improve PHP7 anymore without major changes, > such as the case for PHP 5.6 was.
What is a "major change", if you want to abandon the link to compatibility? Do you mean "headline-grabbing feature", i.e. versioning as a brand?
> With our current model, that means that when we deprecate something, > users got a year to upgrade their code, if they are bleeding edge > users, but most are likely not, so they have more time to upgrade the > code
This is a recipe for massive version fragmentation. When x.3 comes out, some people will be stuck on x.0, some on x.1, some on x.2, etc; library authors won't be able to take advantage of the features introduced in x.3, and everyone has to remember just what's new in each release. I actually think major releases should be *more* common, to reduce the temptation to "bend" the rules, and break compatibility early. The policy could be as simple as "every major release will have between 3 and 5 minor releases". Then the earliest release of 8.0 would be after 7.2 (late 2018 / early 2019), and the latest would be after 7.4 (late 2020 / early 2021). Having a road map in advance also means you can branch early, break things, and know how long you're going to have to maintain that branch for. Regards,
-- Rowan Collins [IMSoP]

Christoph Becker

9 years ago
On 19.11.2016 at 18:23, Rowan Collins wrote:
> On a broader note, I would like to restate my desire for some kind of > road map or plan of roughly when 8.0 is expected, to inform decisions on > things like this. Does "deprecate in 7.2" mean removal in 2 years time, > or 5, or 10? > > Previously I've been answered with "the Big Feature of 8.0 will be JIT", > but I am not a fan of tying the deprecation and feature policy to > "whenever we happen to have a rewrite of the engine ready"; it muddles > product branding with API versioning. If JIT isn't ready for 10 years, > does that mean we have to wait 10 years to break BC? And if it's ready > in 2018, does that mean everything deprecated in 7.2 has to be > immediately dropped after just one year? Should we decouple the Zend > Engine version from the language version, and use separate semantic > versions for each?
IMHO, we should consider introducing a fixed schedule for major releases (say, every 4 years).
-- Christoph M. Becker

Kalle Sommer Nielsen

9 years ago
Hi Christoph 2016-11-19 19:23 GMT+01:00 Christoph M. Becker <cmbecker69@gmx.de>:
> IMHO, we should consider introducing a fixed schedule for major releases > (say, every 4 years).
I think that should depend on a case by case basis for when we are working towards a new version, a lot of awesome work are already in for master that won't be out for at least another year. At the point when we pick RMs for the next branch, then we have in the past evaluated the scope of changes currently planned to be included, what is currently in and what the magical guys at Zend are doing and decide there. Having a fixed, forced major version does not sound that great if we do not have something awesome that could only ever exist in a new major version,
-- regards, Kalle Sommer Nielsen kalle@php.net

Christoph Becker

9 years ago
Hi Kalle! On 19.11.2016 at 19:35, Kalle Sommer Nielsen wrote:
> 2016-11-19 19:23 GMT+01:00 Christoph M. Becker <cmbecker69@gmx.de>: > >> IMHO, we should consider introducing a fixed schedule for major releases >> (say, every 4 years). > > I think that should depend on a case by case basis for when we are > working towards a new version, a lot of awesome work are already in > for master that won't be out for at least another year. At the point > when we pick RMs for the next branch, then we have in the past > evaluated the scope of changes currently planned to be included, what > is currently in and what the magical guys at Zend are doing and decide > there. Having a fixed, forced major version does not sound that great > if we do not have something awesome that could only ever exist in a > new major version,
But this short-dated decision on whether next will be a major or minor is exactly the problem. Consider, for instance, this RFC which targets 7.2 for deprecation and 8.0 for removal. What if we decide in some month that there'll be no 7.2, but rather 8.0 will be next? Would we remove the features without a deprecation phase, or would we deprecate them for 8.0 and remove later? Either way, I'm pretty sure that we would have a lenghty discussion, and might even need another vote. And at least some RFCs and documentation would have to be fixed. At the very least I would suggest to decide whether the next version but one will be major or minor at the same time we tag the first alpha of the next version. I.e. this decision would had been made months ago, and actually all RFCs I've read assume that PHP 7.2 will be next.
-- Christoph M. Becker

Kalle Sommer Nielsen

9 years ago
Hi Christoph 2016-11-19 19:56 GMT+01:00 Christoph M. Becker <cmbecker69@gmx.de>:
> Hi Kalle! > > But this short-dated decision on whether next will be a major or minor > is exactly the problem. Consider, for instance, this RFC which targets > 7.2 for deprecation and 8.0 for removal. What if we decide in some > month that there'll be no 7.2, but rather 8.0 will be next? Would we > remove the features without a deprecation phase, or would we deprecate > them for 8.0 and remove later? Either way, I'm pretty sure that we > would have a lenghty discussion, and might even need another vote. And > at least some RFCs and documentation would have to be fixed.
That is a valid concern I agree. I just have a hard time wrapping my head around what if we don't have anything ground breaking for a major that I would expect in any major, what differences does it then make for it to not be a minor. I'm a little skeptical on having a pre determined plan, I do see pros/cons for both sides of the argument and I reckon the point you raised to be of a possible con of not having a pre determined plan. But I do kinda like Rowan's idea of a major within x or y releases from last major. Gonna think about this for a bit...
-- regards, Kalle Sommer Nielsen kalle@php.net

Rowan Collins

9 years ago
On 19/11/2016 18:35, Kalle Sommer Nielsen wrote:
> Having a fixed, forced major version does not sound that great if we > do not have something awesome that could only ever exist in a new > major version
Again, you're looking at version numbers as primarily a branding thing ("something awesome") rather than a technical thing ("something that breaks compatibility"). I think this is the biggest thing that the formal SemVer standard forces a developer to accept: you don't get to choose when something "deserves" a major version number, you MUST increment it when you break compatibility. As the FAQ on semver.org says, if you reach 42.0.0 very rapidly under SemVer, that's because your API isn't stable; pretending some of those versions are minor releases is just masking the problem. If we adopted SemVer (which I'm not particularly proposing, just offering as comparison) there is absolutely zero chance that 4 years would pass without us having a single change which warranted a major version bump. As soon as you have one feature marked deprecated, then the release where that is removed is a major release, regardless of what else it has. That's why I mentioned divorcing the Engine and Language versions: if we don't want to brand something as "PHP 8" unless it's got shinies, then you could brand it as "PHP 7.3 powered by Zend Engine 4.0" instead. I'm not sure that split does quite work, but it would at least make explicit the difference between brand version and compatibility version. Regards,
-- Rowan Collins [IMSoP]

Kalle Sommer Nielsen

9 years ago
2016-11-19 22:56 GMT+01:00 Rowan Collins <rowan.collins@gmail.com>:
> Again, you're looking at version numbers as primarily a branding thing > ("something awesome") rather than a technical thing ("something that breaks > compatibility").
Yes because that has been our past model for a long time. Like I mentioned, PHP 5.3 should probably have been a major considering the changes it did. It wasn't until PHP 5.3 that we introduced E_DEPREPCATED and actively started taking out problematic features which in the past had caused issues with the usual group of people who don't care to read the manual, so we gave those features a little longer life span while informing the developers that we are gonna remove it. Basically before we started to get all political of things, which is both good and bad, then a new x+1.z or x.z+1 version was based off having a large number of features that branded that version as a whole, and I think that is perfectly fine.
> I think this is the biggest thing that the formal SemVer standard forces a > developer to accept: you don't get to choose when something "deserves" a > major version number, you MUST increment it when you break compatibility. As > the FAQ on semver.org says, if you reach 42.0.0 very rapidly under SemVer, > that's because your API isn't stable; pretending some of those versions are > minor releases is just masking the problem.
If we were to rename past releases to a scheme by SemVer, then that would pretty much have been a yearly major, that is extremely poor versioning in my opinion when we retrain such a high backwards compatibility rate otherwise. I don't like the thought that PHP 5.4 could have been PHP 6 just because we removed safe_mode, that was deprecated in 5.3. That would be a disappointing reason just to go for a new major. I think the main reason we reserve major versions, and have in the past is that the internal API is very compatible across minor versions, 5.x even contained macros for PHP4 extensions to be mostly compatible or even loadable pre 4.3 extensions for a long time if I remember correctly (I think it was Julien that removed that in 5.5).
> If we adopted SemVer (which I'm not particularly proposing, just offering as > comparison) there is absolutely zero chance that 4 years would pass without > us having a single change which warranted a major version bump. As soon as > you have one feature marked deprecated, then the release where that is > removed is a major release, regardless of what else it has.
Same as above, I dislike this rapid jumping in versioning. Though this is my personal opinion, for me as a Core Developer of PHP, I prefer this scheme as it makes sense to me as it is pretty much what it always has been. Taking Chrome, or well Blink as I use Opera, as an example, I don't see the big point in that every few weeks I get a new major version of my browser because some handy new feature was added, might as well have been a minor release, like Opera used to be in the Presto days.
> > That's why I mentioned divorcing the Engine and Language versions: if we > don't want to brand something as "PHP 8" unless it's got shinies, then you > could brand it as "PHP 7.3 powered by Zend Engine 4.0" instead. I'm not sure > that split does quite work, but it would at least make explicit the > difference between brand version and compatibility version.
I don't think that will work as most people when you say the Zend Engine that is not into the PHP.net project will maybe know that its the core of PHP, but nothing more about it so I don't think it makes much sense to suddenly start label releases as such. PHP for almost two decades have only been released with Zend Engine and they are so coupled together today that I doubt you can build LibZend standalone anymore.
-- regards, Kalle Sommer Nielsen kalle@php.net

Rowan Collins

9 years ago
On 19/11/2016 23:05, Kalle Sommer Nielsen wrote:
> 2016-11-19 22:56 GMT+01:00 Rowan Collins <rowan.collins@gmail.com>: >> Again, you're looking at version numbers as primarily a branding thing >> ("something awesome") rather than a technical thing ("something that breaks >> compatibility"). > Yes because that has been our past model for a long time. Like I > mentioned, PHP 5.3 should probably have been a major considering the > changes it did.
Agreed that it's the past model, and agreed that 5.3 was misnamed whichever way you look at it. The fact that something used to be done a particular way doesn't mean that was the best way, though. It's also not what the current release process specifies, in my opinion.
> It wasn't until PHP 5.3 that we introduced > E_DEPREPCATED and actively started taking out problematic features > which in the past had caused issues with the usual group of people who > don't care to read the manual, so we gave those features a little > longer life span while informing the developers that we are gonna > remove it. > > Basically before we started to get all political of things
I'm not sure what you mean by "political". The big challenge which comes up again and again, is that take up of new versions of PHP is low. You can blame the users for that if you like, but the reality is there's no point rushing your shiny feature into a release that 90% of the user base won't install. Well-publicised deprecations, and a strict adherence to compatibility, build trust that upgrading won't be a major headache, meaning new features actually get to users *faster*. And to return to the topic at hand, knowing how long something will be deprecated before it's removed helps people plan ahead.
> If we were to rename past releases to a scheme by SemVer, then that > would pretty much have been a yearly major, that is extremely poor > versioning in my opinion when we retrain such a high backwards > compatibility rate otherwise.
If every release contained breaking changes, then the release process RFC has failed. It would be extremely poor versioning not because we'd somehow run out of version numbers, but because it means we've made upgrading harder than it should be. Let me quote that SemVer FAQ in full:
> /Q: //If even the tiniest backwards incompatible changes to the public > API require a major version bump, won’t I end up at version 42.0.0 > very rapidly?// > // > //A: This is a question of responsible development and foresight. > Incompatible changes should not be introduced lightly to software that > has a lot of dependent code. The cost that must be incurred to upgrade > can be significant. Having to bump major versions to release > incompatible changes means you’ll think through the impact of your > changes, and evaluate the cost/benefit ratio involved./
In reality, we had two very successful minor releases after the release process was agreed: 5.5, and 5.6. I think 7.1 has bent the rules, and I think that's a shame.
> I don't like the thought that PHP 5.4 > could have been PHP 6 just because we removed safe_mode, that was > deprecated in 5.3. That would be a disappointing reason just to go for > a new major.
Agreed, so the answer would be not to remove it yet! If it was really that urgent to remove the feature, then yes, bump the version number to say so; if it could wait for one more minor release, then let it wait. It's an odd example though, because for me by far the biggest break in 5.4 was the removal of call-time pass-by-reference, which was widely used, and very fiddly to remove. But the story of 5.3 and 5.4 is inextricably tied up with the failure of 6.0, so we can come up with all sorts of "what if" scenarios and prove very little about the present and future.
> Same as above, I dislike this rapid jumping in versioning. Though this > is my personal opinion, for me as a Core Developer of PHP, I prefer > this scheme as it makes sense to me as it is pretty much what it > always has been.
That's fine, that's what I mean by "version number as branding". But if we go down that route, we should drop all reference to major versions in our deprecation and compatibility policy, because that's a fundamentally different meaning of "major". For instance, we could have a fixed duration of deprecation, say deprecated for 2 versions, removed in the next. So any features deprecated in 2017's release would be removed in 2019's release, regardless of its version number. In 2018, further features could be deprecated, to be removed in 2020, and so on.
>> That's why I mentioned divorcing the Engine and Language versions > I don't think that will work as most people when you say the Zend > Engine that is not into the PHP.net project will maybe know that its > the core of PHP, but nothing more about it so I don't think it makes > much sense to suddenly start label releases as such.
Sure, I was just brainstorming alternative solutions, since we seem to have very different ideas of what the version number is there for. Ignoring "Zend Engine" in particular, think about Windows prior to 10: the internal (kernel) version number had strict rules, and the marketers could make up whatever name they liked, meaning Windows 7 and 8 were both internally 6.x. Regards,
-- Rowan Collins [IMSoP]

Alice Wonder

9 years ago
On 11/20/2016 02:32 PM, Rowan Collins wrote:
> > I'm not sure what you mean by "political". The big challenge which comes > up again and again, is that take up of new versions of PHP is low. You > can blame the users for that if you like, but the reality is there's no > point rushing your shiny feature into a release that 90% of the user > base won't install. >
For the perspective of a user on this - I always skip a major version. I'm running 5.6.x on my productions, and preparing for 7.1 I am running 7.1.0RC on one test server and my workstation. I'll probably run 7.1 on production fairly soon after release but likely skip 7.2. I skip because once I have a web application deployed, I'm not looking to change it for awhile, security updates sure but I don't need to run the latest major release when the release I have works fine. I suspect many are the same way, and I don't see that as a bad thing. Releases no longer maintained by upstream obviously should not be run, but if the release one has works for the purpose, what problem is solved by upgrading to latest major release? It's time consuming and expensive because there is always code that needs to be changed and tested.

Derick Rethans

9 years ago
On Fri, 18 Nov 2016, Nikita Popov wrote:
> Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC.
I wouldn't deprecate things that 1. have no replacement, 2. are very much in use, or 3. are harmless. __autoload is one of group (2). I think this is used a lot, and would *not* want to deprecate this until PHP 8. I also do not see why (binary) should be removed, as it fits in category 3. In general, I think you should have a good reason *why* to remove them, and just "it's not what we suggest you use" is not good enough. It should be a general *bad* thing, before it should be considered for removal. Right now, the only thing I can think of is removing mbstring.func_overload. For ini settings, you should not throw a deprecation warning if the setting is set to *off*. This covers mbstring.func_overload , but it seems you have changed that since I read this RFC for the first time. cheers, Derick

Daniel Morris

9 years ago
On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote:
> __autoload is one of group (2). I think this is used a lot, and would > *not* want to deprecate this until PHP 8.
Agreed, I still think this is used widely, it would be fine to have it throw an E_DEPRECATED in 7.2 and removed in 8.0. Upgrading to not use __autoload would be trivial. On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote:
> I also do not see why (binary) should be removed, as it fits in category > 3.
Whilst (binary) may be harmless, it's also pointless, since it's just an alias for (string) – I don't think it has wide-enough usage to worry about deprecating it sooner rather than later.
-- Daniel Morris daniel@honestempire.com

Rowan Collins

9 years ago
On 20/11/2016 22:50, Daniel Morris wrote:
> On Sun, 20 Nov 2016, at 10:42 PM, Derick Rethans wrote: >> >__autoload is one of group (2). I think this is used a lot, and would >> >*not* want to deprecate this until PHP 8. > Agreed, I still think this is used widely, it would be fine to have it > throw an E_DEPRECATED in 7.2 and removed in 8.0. Upgrading to not use > __autoload would be trivial.
Note that this would be a "yes" vote, where Derick was implying he would vote "no". I quote:
> The RFC proposes to deprecate the listed functionality in PHP 7.2 and > remove it no later than in PHP 8.0.
Regards,
-- Rowan Collins [IMSoP]

Kalle Sommer Nielsen

9 years ago
Hi 2016-11-18 15:55 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>:
> Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2
I was actually gonna make an RFC for this, but the (real) cast and is_real() function, our third alias for float/double/real could be added to the deprecation list. It doesn't make much sense to keep three aliases where one of them is rarely used in "real" life applications.
-- regards, Kalle Sommer Nielsen kalle@php.net

Kalle Sommer Nielsen

9 years ago
Hi Nikita 2016-11-18 15:55 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>:
> Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2
Another one could be php_sapi_name() which returns a constant value, from which we already have available; PHP_SAPI
-- regards, Kalle Sommer Nielsen kalle@php.net

Maciej Sobaczewski

9 years ago
Hi Kalle W dniu 10.12.2016 o 15:16, Kalle Sommer Nielsen pisze:
> Hi Nikita > > 2016-11-18 15:55 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>: >> Hi internals! >> >> I've submitted this RFC for PHP 7.1 previously, but didn't follow through >> due to time constraints. Now I'd like to propose an extended version for >> PHP 7.2 and vote on it sooner rather than later to avoid a repeat >> performance. >> >> https://wiki.php.net/rfc/deprecations_php_7_2 > > > Another one could be php_sapi_name() which returns a constant value, > from which we already have available; PHP_SAPI >
php_sapi_name() is not unique here - as far as I can tell pi() works the same way. And it's not I'm against such deprecations - I just wonder if we want to make it more general rule for proceeding.

Nikita Popov

9 years ago
On Fri, Nov 18, 2016 at 3:55 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals! > > I've submitted this RFC for PHP 7.1 previously, but didn't follow through > due to time constraints. Now I'd like to propose an extended version for > PHP 7.2 and vote on it sooner rather than later to avoid a repeat > performance. > > https://wiki.php.net/rfc/deprecations_php_7_2 > > The RFC combines a number of deprecation and removal proposals. Each one > will get a separate 2/3 majority vote. The RFC overlaps with some recently > discussed topics (each, binary strings) -- I'm fine with dropping these if > someone has a more specific RFC. > > I expect some of these are no-brainers, while others are more > controversial -- please share your specific concerns. > > Thanks, > Nikita >
I would like to proceed to voting on this RFC soon. There are only two items on this list that I am not entirely certain about: a) assert() with a string argument: Multiple people pointed out that it might be too early to deprecate this function. In particular, some Drupal contributors mentioned that Drupal currently uses assert() with string arguments as an optimization to avoid executing certain code in production. I have changed the RFC to clarify that assert() with a string argument will only throw a deprecation warning if assertions are enabled. As such projects have a choice between either using the non-string form and incurring a penalty in production on PHP 5 (my default recommendation), or using the string form and incurring a penalty in debug mode on PHP >=7.2 (the penalty being caused by deprecation warnings). The latter might be preferable in some cases, especially as the string form of assert() is already very slow if assertions are enabled. b) The $errcontext parameter for the error handler. A few people raised concerns about this, but on further discussion it always turned out that they were interested in information provided by debug_backtrace(), not by $errcontext. I have now added an explicit reference to debug_backtrace() to the RFC. I will likely proceed with both deprecations included and let voting decide on the question. Regards, Nikita

Kalle Sommer Nielsen

9 years ago
Hi Nikita 2016-12-21 17:46 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>:
> I will likely proceed with both deprecations included and let voting decide > on the question.
What about adding the mysqli embedded server API to the list? It's been experimental for so long, and not even been ported to PHP7 (see ext/mysqli/mysqli_embedded.c), its not supported by mysqlnd (as per comments in the m4) and never had the /D flag for Windows (or so it seems).
> Regards, > Nikita
-- regards, Kalle Sommer Nielsen kalle@php.net

Nikita Popov

9 years ago
On Thu, Dec 22, 2016 at 3:55 AM, Kalle Sommer Nielsen <kalle@php.net> wrote:
> Hi Nikita > > 2016-12-21 17:46 GMT+01:00 Nikita Popov <nikita.ppv@gmail.com>: > > I will likely proceed with both deprecations included and let voting > decide > > on the question. > > What about adding the mysqli embedded server API to the list? It's > been experimental for so long, and not even been ported to PHP7 (see > ext/mysqli/mysqli_embedded.c), its not supported by mysqlnd (as per > comments in the m4) and never had the /D flag for Windows (or so it > seems). >
I don't think this requires deprecation, it can be directly dropped. Deprecating it would require making it compile first. Given that it doesn't compile currently, hasn't compiled since the PHP 7 release and there hasn't been a single complaint, it is safe to say that nobody uses this. Nikita

Net Mo

9 years ago
(i didn't read the above discussion) Can we deprecate also the php5-style assert()? It wasn't used a lot anyway. Thanks :P

Stas Malyshev

9 years ago
Hi!
>> https://wiki.php.net/rfc/deprecations_php_7_2
Reading through the list, I find several categories: Completely ok: (unset) - don't see any sane use case anyway gmp_random Can cause breakage but it's ok: $php_errormsg __autoload mbstring.func_overload parse_str() - people can use it in functions, it doesn't have to be globals. But it's cleaner with second arg. $errcontext Don't see a reason to remove: (binary) cast and b"" - yes, they are not currently doing anything. But they don't also hurt anything. High breakage potential: each() - I've seen a lot of code using each. Yes, it's not the best way. A lot of people write code not in absolutely best way but in a way they like to. Argument about list() proposed in RFC makes little sense to me - since problem is with list() and not each() why each() should be deprecated because of it? And I certainly object its removal. create_function() - yes, there are closures now. But there's a lot of code created when there were none, and that code works, and there's no reason to break it. I'd probably be OK with deprecation warning but not with removal. Special case: assert() - if the string arg is a security issue, deprecating it achieves nothing. So I'm not sure I understand the argument for deprecation - if string assert is a problem we probably should make assert() construct instead check if assert is used in eval form, not by argument count?
-- Stas Malyshev smalyshev@gmail.com

Alexander Lissachenko

9 years ago
Hi, internals! I want to propose to deprecate one more weird feature of PHP called "comparison of different types" http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.types. Here you can check one simple example https://3v4l.org/kCOAf to see why it should be deprecated. It would be nice to deprecate all comparison operators between different types and throw an exception later in future version of PHP. Operators that should be allowed for comparison of different types are the following: ==, !=, ===, !==, <>. Operators to deprecate for comparison of different types are the following:
>, <, >=, <=, <=>
I also think about deprecation of string/object/array comparison with operators like greater/less, because it's hard to understand results for '1000' < '0xabc1' (see https://3v4l.org/o3iLj) or even object comparison https://3v4l.org/5At1l Thanks! 2016-12-27 9:52 GMT+03:00 Stanislav Malyshev <smalyshev@gmail.com>:

Alexander Lissachenko

9 years ago
There was small typo in my previous link to object comparison: new one is https://3v4l.org/tMokY 2016-12-27 14:33 GMT+03:00 Alexander Lisachenko <lisachenko.it@gmail.com>:

Nicolas Grekas

9 years ago
Hi Nikita, hi all, https://wiki.php.net/rfc/deprecations_php_7_2 I just realized that in Symfony, we use the $errcontext argument of error handlers to work around the limitation of __toString not being able to throw. Excerpt from https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/ErrorHandler.php#L439 : // Here, we know trigger_error() has been called from __toString(). // HHVM is fine with throwing from __toString() but PHP triggers a fatal error instead. // A small convention allows working around the limitation: // given a caught $e exception in __toString(), quitting the method with // `return trigger_error($e, E_USER_ERROR);` allows this error handler // to make $e get through the __toString() barrier. This is a hack, but that's what the Debug component is about: leverage several hacks and ship them as a set of useful experience-enhancers to devs. In short, I'm all for deprecating $errcontext, and looking at the ongoing vote it'll be accepted soon. BUT, it would great to fix the inability of __toString to throw in 7.2 also. Regards, Nicolas

Stas Malyshev

9 years ago
Hi!
> BUT, it would great to fix the inability of __toString to throw in 7.2 also.
That might be a bit harder to do. __toString does not throw because it's used in many contexts inside the engine where you can't just drop what you're doing and start processing the exception - like in the middle of function accepting parameters, or in the middle of calculating the expression, in the middle of executing a function call, etc. I'm not saying it's impossible to do, but it would require adding a lot of very carefully written code so that interrupting whatever the engine was doing is safe, and even then not clear what to do with extensions which won't have this code.
-- Stas Malyshev smalyshev@gmail.com