[RFC] Deprecations for 7.4

  106012
June 21, 2019 15:20 kalle@php.net (Kalle Sommer Nielsen)
Greetings Internals

Nikita and I would like to open the discussion for the RFC:
"Deprecations for 7.4", this RFC targets a larger set of various
features targeting for deprecation in 7.4 with the intention of
removal in PHP 8.0.

https://wiki.php.net/rfc/deprecations_php_7_4

If there is no major objections to this RFC, then voting will begin in
a 2 weeks time.

Regards,
Nikita & Kalle
  106013
June 21, 2019 16:24 rowan.collins@gmail.com (Rowan Collins)
On Fri, 21 Jun 2019 at 16:20, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Greetings Internals > > Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in PHP 8.0. > > https://wiki.php.net/rfc/deprecations_php_7_4 >
The mention of "convert_cyr_string" here makes me want to revisit the oft-abused "utf8encode" and "utf8decode" functions. The downside in all cases is that PHP has no single correct function for encoding conversions, with mbstring, intl, and iconv all offering slightly different implementations, and all distributed as optional extensions. Is there some way we can bless a single conversion function, in core, and recommend that in deprecation notices? Regards, -- Rowan Collins [IMSoP]
  106014
June 21, 2019 16:54 theodorejb@outlook.com (Theodore Brown)
On Fri, Jun 21, 2019 at 10:20 AM Kalle Sommer Nielsen <kalle@php.net> wrote:

> Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in PHP 8.0. > > https://wiki.php.net/rfc/deprecations_php_7_4
It's still unclear what is being proposed for the register_argc_argv ini directive. When the ini setting is removed, will the `$argv` and `$argc` variables always be available on CLI SAPIs, and never be available on non-CLI SAPIs? If that's the case, I'd propose a deprecation notice in PHP 7.4 when using `-d register_argc_argv=0` on the command line, and when accessing the predefined `$argv` or `$argc` variables from non-CLI SAPIs. Thanks, Theodore
  106015
June 21, 2019 17:08 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Jun 21, 2019 at 6:54 PM Theodore Brown <theodorejb@outlook.com>
wrote:

> On Fri, Jun 21, 2019 at 10:20 AM Kalle Sommer Nielsen <kalle@php.net> > wrote: > > > Nikita and I would like to open the discussion for the RFC: > > "Deprecations for 7.4", this RFC targets a larger set of various > > features targeting for deprecation in 7.4 with the intention of > > removal in PHP 8.0. > > > > https://wiki.php.net/rfc/deprecations_php_7_4 > > It's still unclear what is being proposed for the register_argc_argv > ini directive. When the ini setting is removed, will the `$argv` and > `$argc` variables always be available on CLI SAPIs, and never be > available on non-CLI SAPIs? > > If that's the case, I'd propose a deprecation notice in PHP 7.4 when > using `-d register_argc_argv=0` on the command line, and when accessing > the predefined `$argv` or `$argc` variables from non-CLI SAPIs.
I've update the RFC to say that the option will be removed without deprecation, with argv always available on CLI and never on non-CLI. Throwing a deprecation warning when accessing $argv in non-CLI SAPIs is too complicated and/or unreliable. Nikita
  106021
June 21, 2019 23:08 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I've update the RFC to say that the option will be removed without > deprecation, with argv always available on CLI and never on non-CLI. > Throwing a deprecation warning when accessing $argv in non-CLI SAPIs is too > complicated and/or unreliable.
So this means CGI binary would not have $argv? AFAIK it has it set now. What about phpdbg and embed SAPI? Or do you mean CLI/non-CLI some more subtle distinction then just "cli" SAPI? -- Stas Malyshev smalyshev@gmail.com
  106016
June 21, 2019 17:54 claude.pache@gmail.com (Claude Pache)
> Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen <kalle@php.net> a écrit : > > Greetings Internals > > Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in PHP 8.0. > > https://wiki.php.net/rfc/deprecations_php_7_4 > > If there is no major objections to this RFC, then voting will begin in > a 2 weeks time. > > Regards, > Nikita & Kalle > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I object to the following deprecations: ------------ apache_request_headers(). The function has that name because once upon a time it was available only when PHP run as an Apache module. But although it (and its irregularly-named alias `getallheaders()`) is now available somewhere else, the functionality has not changed for those that run PHP as an Apache module. Also, according to the documentation, another function, `apache_response_headers()`, is also available to other SAPIs. However, it has the benefit of not having a documented alias, so that it can escape the deprecation proposal? Note also the existence of `nsapi_request_headers()` function that (according to the documentation) does the same thing than `getallheaders()` when PHP runs as a NSAPI module. And last but not least, `*_request_headers()`is more precisely named than `getallheaders()` (given the existence of `*_response_header()` functions). ------------ is_writeable(). That “writeable” is “a spelling mistake” (as opposed to an “uncommon alternative spelling”) is an opinion that is not really proveable. ------------ —Claude
  106017
June 21, 2019 18:15 bishop@php.net (Bishop Bettini)
On Fri, Jun 21, 2019, 13:54 Claude Pache pache@gmail.com> wrote:

> > > > Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen <kalle@php.net> a écrit : > > > > Greetings Internals > > > > Nikita and I would like to open the discussion for the RFC: > > "Deprecations for 7.4", this RFC targets a larger set of various > > features targeting for deprecation in 7.4 with the intention of > > removal in PHP 8.0. > > > > https://wiki.php.net/rfc/deprecations_php_7_4 > > > > If there is no major objections to this RFC, then voting will begin in > > a 2 weeks time. > > I object to the following deprecations: > > ------------ > > is_writeable(). > > That “writeable” is “a spelling mistake” (as opposed to an “uncommon > alternative spelling”) is an opinion that is not really probable. >
Agreed. http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html "With this in mind, what about "writable" and its variant "writeable"? While the dictionary says "writable" is correct, I consider that spelling harmful. Search for "table" and you'll hit "wri*table*", which is undoubtedly a false positive."
>
  106018
June 21, 2019 18:46 claude.pache@gmail.com (Claude Pache)
> Le 21 juin 2019 à 20:15, Bishop Bettini <bishop@php.net> a écrit : > > On Fri, Jun 21, 2019, 13:54 Claude Pache pache@gmail.com <mailto:claude.pache@gmail.com>> wrote: > > > > Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen <kalle@php.net <mailto:kalle@php.net>> a écrit : > > > > Greetings Internals > > > > Nikita and I would like to open the discussion for the RFC: > > "Deprecations for 7.4", this RFC targets a larger set of various > > features targeting for deprecation in 7.4 with the intention of > > removal in PHP 8.0. > > > > https://wiki.php.net/rfc/deprecations_php_7_4 <https://wiki.php.net/rfc/deprecations_php_7_4> > > > > If there is no major objections to this RFC, then voting will begin in > > a 2 weeks time. > > I object to the following deprecations: > > ------------ > > is_writeable(). > > That “writeable” is “a spelling mistake” (as opposed to an “uncommon alternative spelling”) is an opinion that is not really probable. > > Agreed. > > http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html <http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html> > > "With this in mind, what about "writable" and its variant "writeable"? While the dictionary says "writable" is correct, I consider that spelling harmful. Search for "table" and you'll hit "writable", which is undoubtedly a false positive."
Your spell checker has incorrectly “fixed” the last word of my message... —Claude
  106019
June 21, 2019 18:50 bishop@php.net (Bishop Bettini)
On Fri, Jun 21, 2019 at 2:46 PM Claude Pache pache@gmail.com> wrote:

> > > > Le 21 juin 2019 à 20:15, Bishop Bettini <bishop@php.net> a écrit : > > > > On Fri, Jun 21, 2019, 13:54 Claude Pache pache@gmail.com > <mailto:claude.pache@gmail.com>> wrote: > > > > > > > Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen <kalle@php.net kalle@php.net>> a écrit : > > > > > > Greetings Internals > > > > > > Nikita and I would like to open the discussion for the RFC: > > > "Deprecations for 7.4", this RFC targets a larger set of various > > > features targeting for deprecation in 7.4 with the intention of > > > removal in PHP 8.0. > > > > > > https://wiki.php.net/rfc/deprecations_php_7_4 < > https://wiki.php.net/rfc/deprecations_php_7_4> > > > > > > If there is no major objections to this RFC, then voting will begin in > > > a 2 weeks time. > > > > I object to the following deprecations: > > > > ------------ > > > > is_writeable(). > > > > That “writeable” is “a spelling mistake” (as opposed to an “uncommon > alternative spelling”) is an opinion that is not really probable. > > > > Agreed. > > > > http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html < > http://cerebriform.blogspot.com/2015/05/writable-is-wrong.html> > > > > "With this in mind, what about "writable" and its variant "writeable"? > While the dictionary says "writable" is correct, I consider that spelling > harmful. Search for "table" and you'll hit "writable", which is > undoubtedly a false positive." > > Your spell checker has incorrectly “fixed” the last word of my message... > —Claude >
The irony's not lost on me. Yet, apologies: human error. I manually typed it, as I was working on my mobile and deleted whilst replying. s/probable/provable/g.
  106020
June 21, 2019 23:04 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in PHP 8.0.
My first question for many of those is - why? I.e. it deprecates a bunch of niche functions. Most people do not use these functions, so they probably don't care. Those they do use them would find their code broken or produce new warnings and needs to be changed. I have hard time identifying whose life would be made better by these changes. Now, if some of these functions are hopelessly broken or have no valid use cases - like magic quotes - then phasing them out makes sense, and the audience whose life can be made better are people who use those unaware of them being broken, or plan to use them and would thus have broken code unless we warn them (or remove the functions, eventually). But for functions that work just fine, I see absolutely no reason to introduce friction without any apparent upside. For the specifics, I think things like removing allow_url_include requires separate RFC. It's a serious functionality change, and bundling it with 20 or so other changes would not allow to properly consider it. In general mass-change RFCs usually are not very conductive to properly discussing each specific change, but mixing changes of different types makes it even worse. Same probably holds for "Unbinding $this from non-static closures" but for different reasons - this looks like a consistency change which is necessary to bring Closure in compliance with the rest of the engine. If non-$this call is not supported in PHP 8, then bindTo(null) should produce an error, not sure it even needs an RFC for that. -- Stas Malyshev smalyshev@gmail.com
  106022
June 22, 2019 07:22 kalle@php.net (Kalle Sommer Nielsen)
Hi
Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <smalyshev@gmail.com>:
> My first question for many of those is - why? I.e. it deprecates a bunch > of niche functions. Most people do not use these functions, so they > probably don't care. Those they do use them would find their code broken > or produce new warnings and needs to be changed. I have hard time > identifying whose life would be made better by these changes. > > Now, if some of these functions are hopelessly broken or have no valid > use cases - like magic quotes - then phasing them out makes sense, and > the audience whose life can be made better are people who use those > unaware of them being broken, or plan to use them and would thus have > broken code unless we warn them (or remove the functions, eventually). > > But for functions that work just fine, I see absolutely no reason to > introduce friction without any apparent upside.
While I understand where you are coming from on this, I do think that functionality that is better supported by dedicated extensions to do the job instead of providing some functions in the standard library that converts from a few specific encodings to another: convert_cyr_string() -- This uses a non standard set of encoding names and only for cyrillic like encodings, what justifications is there for keeping this in the standard library over using ext/intl with UConverter that supports a much larger set of encodings in a much more generic way for more than just cyrillic encodings? hebrev(), hebrevc() -- These functions were designed for the web era pre IE6 where some browsers did not support , what use case is there for these now that the web has evolved so much in the past two decades since these were added to do this on a backend? One of the biggest complaints we have in regards to the standard library is that it is inconsistent, it provides very niche functionality that is better supported elsewhere. I think it is a perfect opportunity to review these legacy blocks and direct users to better alternatives instead of us having to support many ways of doing the same thing. Why should the standard library support only a subset of conversion functionality that is so niche and already supported much more fluently and abstract in extensions dedicated for the matter. I personally think that is a very valid reason to consider these functions for deprecations. We have a large set of aliases that easily can make the standard library feel convoluted and therefore also creates a certain technical depth as a side-effect. The cost of having to convert these functions is a small price to allow the language to evolve in my honest opinion.
> For the specifics, I think things like removing allow_url_include > requires separate RFC. It's a serious functionality change, and bundling > it with 20 or so other changes would not allow to properly consider it. > In general mass-change RFCs usually are not very conductive to properly > discussing each specific change, but mixing changes of different types > makes it even worse.
I will have a chat with Nikita regarding this. -- regards, Kalle Sommer Nielsen kalle@php.net
  106023
June 22, 2019 07:44 krakjoe@gmail.com (Joe Watkins)
Just a note on process.

It is not necessary to hold multiple RFC's:

> For procedural reasons, multiple RFCs may be combined into one, in which case there may be multiple primary votes.
> Combining multiple RFCs into one does not allow turning a primary vote into a secondary vote.
In general, something is considered a primary vote if it could be conducted independently of other primary votes in the same RFC - ie, it is not an implementation detail. So, what we have here is multiple primary votes ... [1] https://wiki.php.net/rfc/voting Cheers Joe On Sat, 22 Jun 2019 at 09:23, Kalle Sommer Nielsen <kalle@php.net> wrote:
> Hi > Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev < > smalyshev@gmail.com>: > > My first question for many of those is - why? I.e. it deprecates a bunch > > of niche functions. Most people do not use these functions, so they > > probably don't care. Those they do use them would find their code broken > > or produce new warnings and needs to be changed. I have hard time > > identifying whose life would be made better by these changes. > > > > Now, if some of these functions are hopelessly broken or have no valid > > use cases - like magic quotes - then phasing them out makes sense, and > > the audience whose life can be made better are people who use those > > unaware of them being broken, or plan to use them and would thus have > > broken code unless we warn them (or remove the functions, eventually). > > > > But for functions that work just fine, I see absolutely no reason to > > introduce friction without any apparent upside. > > While I understand where you are coming from on this, I do think that > functionality that is better supported by dedicated extensions to do > the job instead of providing some functions in the standard library > that converts from a few specific encodings to another: > > convert_cyr_string() -- This uses a non standard set of encoding names > and only for cyrillic like encodings, what justifications is there for > keeping this in the standard library over using ext/intl with > UConverter that supports a much larger set of encodings in a much more > generic way for more than just cyrillic encodings? > > hebrev(), hebrevc() -- These functions were designed for the web era > pre IE6 where some browsers did not support lang="he">, what use case is there for these now that the web has > evolved so much in the past two decades since these were added to do > this on a backend? > > One of the biggest complaints we have in regards to the standard > library is that it is inconsistent, it provides very niche > functionality that is better supported elsewhere. I think it is a > perfect opportunity to review these legacy blocks and direct users to > better alternatives instead of us having to support many ways of doing > the same thing. Why should the standard library support only a subset > of conversion functionality that is so niche and already supported > much more fluently and abstract in extensions dedicated for the > matter. I personally think that is a very valid reason to consider > these functions for deprecations. > > We have a large set of aliases that easily can make the standard > library feel convoluted and therefore also creates a certain technical > depth as a side-effect. The cost of having to convert these functions > is a small price to allow the language to evolve in my honest opinion. > > > For the specifics, I think things like removing allow_url_include > > requires separate RFC. It's a serious functionality change, and bundling > > it with 20 or so other changes would not allow to properly consider it. > > In general mass-change RFCs usually are not very conductive to properly > > discussing each specific change, but mixing changes of different types > > makes it even worse. > > I will have a chat with Nikita regarding this. > > > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  106034
June 22, 2019 19:38 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> In general, something is considered a primary vote if it could be > conducted independently of other primary votes in the same RFC - ie, it > is not an implementation detail. > > So, what we have here is multiple primary votes ...
I am not talking bureaucracy here, I'm talking about discussion on the merits. It is virtually impossible to discuss 20 proposals on the merits within a single thread. Of course, in this RFC there are not 20 different proposals - most of it is of the same type, deprecating certain function, usually for the same reason (which I coincidentally believer is wrong, but that's for another thread). However, some of these are of a different types, and I think they'd be better as separate RFCs. Especially the allow_url_include thing and closure $this thing (which I'm not sure even needs an RFC if I understand the argument right - we pretty much have no choice there). Discussing them all together would be messy. -- Stas Malyshev smalyshev@gmail.com
  106024
June 22, 2019 10:41 claude.pache@gmail.com (Claude Pache)
> Le 22 juin 2019 à 09:22, Kalle Sommer Nielsen <kalle@php.net> a écrit : > > Hi > Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <smalyshev@gmail.com>: >> My first question for many of those is - why? I.e. it deprecates a bunch >> of niche functions. Most people do not use these functions, so they >> probably don't care. Those they do use them would find their code broken >> or produce new warnings and needs to be changed. I have hard time >> identifying whose life would be made better by these changes. >> >> Now, if some of these functions are hopelessly broken or have no valid >> use cases - like magic quotes - then phasing them out makes sense, and >> the audience whose life can be made better are people who use those >> unaware of them being broken, or plan to use them and would thus have >> broken code unless we warn them (or remove the functions, eventually). >> >> But for functions that work just fine, I see absolutely no reason to >> introduce friction without any apparent upside. > > While I understand where you are coming from on this, I do think that > functionality that is better supported by dedicated extensions to do > the job instead of providing some functions in the standard library > that converts from a few specific encodings to another: > > convert_cyr_string() -- This uses a non standard set of encoding names > and only for cyrillic like encodings, what justifications is there for > keeping this in the standard library over using ext/intl with > UConverter that supports a much larger set of encodings in a much more > generic way for more than just cyrillic encodings? > > hebrev(), hebrevc() -- These functions were designed for the web era > pre IE6 where some browsers did not support lang="he">, what use case is there for these now that the web has > evolved so much in the past two decades since these were added to do > this on a backend? > > One of the biggest complaints we have in regards to the standard > library is that it is inconsistent, it provides very niche > functionality that is better supported elsewhere. I think it is a > perfect opportunity to review these legacy blocks and direct users to > better alternatives instead of us having to support many ways of doing > the same thing. Why should the standard library support only a subset > of conversion functionality that is so niche and already supported > much more fluently and abstract in extensions dedicated for the > matter. I personally think that is a very valid reason to consider > these functions for deprecations. > > We have a large set of aliases that easily can make the standard > library feel convoluted and therefore also creates a certain technical > depth as a side-effect. The cost of having to convert these functions > is a small price to allow the language to evolve in my honest opinion. >
PHP has indeed a sheer number of old-school functions and of niche functions, but as developer, they don’t bother me as long as I don’t see them. One occasion where I am bothered, because I see them, is when I explore the manual in order to find a function that does some job. Let’s take for example the Session Functions: https://www.php.net/manual/en/ref.session.php <https://www.php.net/manual/en/ref.session.php> In the Table of Contents, functions that are actually useful (e.g., `session_start()`) are intermixed with legacy functions that relate to some obsolete way to handle session variables (e.g. `session_register()`). For the particular case of Session functions, there is *some* progress since few years ago (the days of PHP 5.2), because obsolete functions are clearly marked as such on their individual documentation page (https://www.php.net/manual/en/function.session-register.php <https://www.php.net/manual/en/function.session-register.php>; although the pink Warning box ought to be at the very top of the page, so I’m not in danger to actually read the documentation before realising that it is obsolete). But the Table of Contents still needs to be reorganised... Now, let’s take the manual of String Functions: https://www.php.net/manual/en/ref.strings.php <https://www.php.net/manual/en/ref.strings.php> Those may be separated in two groups: the first one for those that are recommended/useful for modern code, and the second one for legacy functions such as `convert_cyr_string()` and `hebrevc()` that provide functionality that are hardly useful today or that are better handled by some other mean. Moreover, for each of those functions, a pink Warning box might be placed at the very top of their documentation page, stating that such function is probably not useful or recommended for new or refactored code, and pointing to better alternatives when appropriate. *However*, such documentation improvement, does *not* imply throwing a deprecation warning each time the functionality is used. There is no issue for legacy code base to continue to use it as long as it is not broken, and as long as I don’t see it. —Claude
  106025
June 22, 2019 10:43 zeev@php.net (Zeev Suraski)
On Sat, Jun 22, 2019 at 10:23 AM Kalle Sommer Nielsen <kalle@php.net> wrote:

> Hi > Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev < > smalyshev@gmail.com>: > > My first question for many of those is - why? I.e. it deprecates a bunch > > of niche functions. Most people do not use these functions, so they > > probably don't care. Those they do use them would find their code broken > > or produce new warnings and needs to be changed. I have hard time > > identifying whose life would be made better by these changes. > > > > Now, if some of these functions are hopelessly broken or have no valid > > use cases - like magic quotes - then phasing them out makes sense, and > > the audience whose life can be made better are people who use those > > unaware of them being broken, or plan to use them and would thus have > > broken code unless we warn them (or remove the functions, eventually). > > > > But for functions that work just fine, I see absolutely no reason to > > introduce friction without any apparent upside. > > While I understand where you are coming from on this, I do think that > functionality that is better supported by dedicated extensions to do > the job instead of providing some functions in the standard library > that converts from a few specific encodings to another: >
Kalle, I see very few ways in which you'd be able to convince anybody whose code was impacted by these removals that they're better off having to audit their code and learn new library semantics - instead of, well, doing nothing. I view this in the same trend as the deprecation of short_tags - deprecations that may make us feel good, make for a 'more proper' code base, and bring hassle to our userbase while aiding absolutely no-one in the process.
> convert_cyr_string() -- This uses a non standard set of encoding names > and only for cyrillic like encodings, what justifications is there for > keeping this in the standard library over using ext/intl with > UConverter that supports a much larger set of encodings in a much more > generic way for more than just cyrillic encodings? >
Simple - it harms nobody to keep it, and removing it aids nobody.
> hebrev(), hebrevc() -- These functions were designed for the web era > pre IE6 where some browsers did not support lang="he">, what use case is there for these now that the web has > evolved so much in the past two decades since these were added to do > this on a backend? >
I've seen hebrev() used as recently as a couple of years ago and given that I'm not very active in the local community - it's probably still being used in all sorts of use cases when interacting with old legacy systems (e.g. IBM i). How are you assuming it's not in use? One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche > functionality that is better supported elsewhere.
While I've heard the former complaint very frequently (and I agree with it entirely), I've quite literally *never* heard the latter complaint. Not once. Niche functionality doesn't bug anybody. Inconsistent core functionality bugs mostly everyone. Bundling the two as if they're the same, or even similar - is wrong. Niche functionality isn't in the way of anybody - and while it's mostly of no use for most people, the few people who do need it would often be remarkably thankful for finding it available (hebrev() certainly falls in that category). These functions have zero negative footprint - they consume virtually no memory, they don't slow anything down, and I'd feel very confident arguring they do not pollute the namespace in any meaningful way (if anybody here ever bumped into someone that was upset about hebrev() being taken, please raise your hand). Instead of removing functionality that most find useless but some found invaluable - why don't we introduce a new extension, 'legacy', that will include these functions? It can even be disabled by default. That way we don't needlessly and pointlessly make the upgrade path more difficult - or at least, we make it just marginally so (you'd be able to eliminate a class of needless compatibility breakages that would otherwise send you auditing and researching new ways to do exactly the same thing - by simply turning on an extension). I think it is a
> perfect opportunity to review these legacy blocks and direct users to > better alternatives instead of us having to support many ways of doing > the same thing. Why should the standard library support only a subset > of conversion functionality that is so niche and already supported > much more fluently and abstract in extensions dedicated for the > matter. I personally think that is a very valid reason to consider > these functions for deprecations. > > We have a large set of aliases that easily can make the standard > library feel convoluted and therefore also creates a certain technical > depth as a side-effect. The cost of having to convert these functions > is a small price to allow the language to evolve in my honest opinion. >
Again, I think our standard library certainly suffers from defficiencies - but I have a hard time accepting that niche functions is anywhere near the top of that list, or that it's even on it to begin with. The key problems of our standard libraries are inconsistencies in naming, inconsistencies in argument definitions and sometimes inconsistencies in behavior. Personally, I think we should actually consider tackling these with a newly designed standard library that would be available via a new top level namespace - *without* interfering with the existing one - which perhaps we can then deprecate by 2030. That would actually bring tremendous value to end users, unlike some of these deprecations. To summarize: 1. Reconsider the proposal to deprecate useful (albeit niche) functions like convert_cyr_string(), hebrev(), money_format() and others.. These deprecations bring virtually zero value but very non-zero headache to affected users. I've yet to bump into a single person, ever, that told me how happy they were with version X.Y deprecating feature Z. Complaints? That's a different story. 2. In case you do want to move forward with them - consider moving them to a new 'legacy' extension instead of outright removing them. Perhaps this can be a solution for short_tags as well, and it can also be a longer-term compromise between the motivation to 'clean up' the language, and the hassle it inflicts on our users when they want to upgrade (which results in longer upgrade cycles and consequently worse security overall). 3. I think we'd all be better off focusing on the real deffficiencies of our standard library. Deprecating's easy, but it's also not very useful. If we can introduce a new, fixed standard library in PHP 8 - it can be a game changer. Thanks, Zeev
  106033
June 22, 2019 19:31 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> While I understand where you are coming from on this, I do think that > functionality that is better supported by dedicated extensions to do > the job instead of providing some functions in the standard library > that converts from a few specific encodings to another:
It may be supported by other extensions (btw did anybody verify that it actually is and gives the same results?), but this is not the reason per se to remove old working functions. There's a lot of duplication in programming languages - all (Turing-complete) languages ultimately do the same thing, and most practical languages have way more syntax and utility functions than strictly necessary to achieve desired outcome. This is because redundancy in expressiveness improves productivity. Here we have the reverse - we are forcing people who have working code to go back and rewrite it to essentially achieve the same result we already have - negative productivity. I don't see a point in doing this.
> convert_cyr_string() -- This uses a non standard set of encoding names > and only for cyrillic like encodings, what justifications is there for > keeping this in the standard library over using ext/intl with
It works.
> hebrev(), hebrevc() -- These functions were designed for the web era > pre IE6 where some browsers did not support lang="he">, what use case is there for these now that the web has > evolved so much in the past two decades since these were added to do > this on a backend?
I see multiple references to it in code online. If it works for people that use it - why touch it? I even see porting it to other languages, like Javascript. Pretty weird for a function that nobody ever needs, isn't it?
> One of the biggest complaints we have in regards to the standard > library is that it is inconsistent, it provides very niche > functionality that is better supported elsewhere. I think it is a
I don't see it as a complaint at all. "Library provides many functions" - this is a *complaint*?! This is pretty much why PHP became popular! I know there are people online that enjoy writing nitpicky snide articles about how PHP is "inconsistent". I say - let them. Internet is big, anybody can write anything, it's not a reason to take to heart everything random people on the internet write. Satisfying those people - some of whom aren't even PHP users - is infinitely less important than the time of actual PHP users that actually use the language. And I do not see who of the actual PHP users these removals would help. "Consistency" is only helpful when it improves something and makes work easier. Nothing is made easier by removing functions that work.
> the same thing. Why should the standard library support only a subset > of conversion functionality that is so niche and already supported > much more fluently and abstract in extensions dedicated for the > matter. I personally think that is a very valid reason to consider > these functions for deprecations.
It is very common in virtually all programming languages to have utility functions to support special cases, even if there's a library that supports more generic case. You have your regular expression library, and then you have functions that parse dates, or numbers, or phone numbers - even though regex library alone enough to implement those. It is a very common and standard practice. Moreover, we're not talking about introducing new functionality here - we're talking about removing functionality that people *already use in their code*. The bar for this should be super-high. In fact, excluding clear blunders like magic quotes, etc. if we never ever removed a working function, I'd be fine even with that. But if we decide to remove, it should be for reasons far better than "you can do it with other functions" - that never was the PHP way and shouldn't be.
> We have a large set of aliases that easily can make the standard > library feel convoluted and therefore also creates a certain technical
What you call "convoluted" I call "convenient and versatile". Having many functions to help people do what they need is good. We don't pay per function. There's no goal to have as few functions as possible.
> depth as a side-effect. The cost of having to convert these functions > is a small price to allow the language to evolve in my honest opinion.
I don't see how this is "evolving", if you understand evolving as getting more fit for the purpose. I do not recognize "having as few functions as possible" as a goal worth pursuing, so what's the point? -- Stas Malyshev smalyshev@gmail.com
  106039
June 22, 2019 21:16 cmbecker69@gmx.de ("Christoph M. Becker")
On 22.06.2019 at 21:31, Stanislav Malyshev wrote:

>> While I understand where you are coming from on this, I do think that >> functionality that is better supported by dedicated extensions to do >> the job instead of providing some functions in the standard library >> that converts from a few specific encodings to another: > > It may be supported by other extensions (btw did anybody verify that it > actually is and gives the same results?), but this is not the reason per > se to remove old working functions. There's a lot of duplication in > programming languages - all (Turing-complete) languages ultimately do > the same thing, and most practical languages have way more syntax and > utility functions than strictly necessary to achieve desired outcome. > This is because redundancy in expressiveness improves productivity. > Here we have the reverse - we are forcing people who have working code > to go back and rewrite it to essentially achieve the same result we > already have - negative productivity. I don't see a point in doing this.
An alternative of rewriting such code would be to have the function defined somewhere else; this could be in userland code (and maybe somebody will make a composer package available), and this could also be in a custom extension (and perhaps somebody publishes a respective extension on PECL). Thanks, Christoph
  106036
June 22, 2019 20:21 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

enable_dl - I am not clear what is proposed - to remove dl()
functionality in PHP 8 completely, even in CLI? Or to keep it in CLI
always on and remove the directive?
My opinion: drop the directive, let the SAPI decide if dl() is possible,
with CLI keeping it. Not sure about embed though. But I guess if
somebody needs it in embed, they probably could patch it so it enables
the dl(). Not sure how easy it would be to make this per-SAPI decision
though...

The 'real' type - see no reason to touch it, it doesn't hurt anybody.

hebrev, hebrevc, apache_request_headers, is_writeable,
convert_cyr_string, money_format, restore_include_path - leave them in
peace (argued why in another thread). Maybe legacy extension as Zeev
suggested, I'm fine with that.

Magic quotes and all related - burn with fire. Magic quotes was a
mistake, and here my BC inner voice is not able to say anything in its
favor.

array_key_exists(object) - fine with dropping object behavior. It does
say "array".
And btw, can we actually make it work with ArrayAccess properly?

INPUT_SESSION & INPUT_REQUEST - if they weren't implemented, drop them.
No point in keeping stuff that doesn't work.

register_argc_argv - support making $argc/$argv always available in CLI
but not sure about the definition of CLI. Does CGI qualify? Does embed?
This worries me a bit. Same situation as in dl() - it's like we need
some ini setting that is only accessible to SAPIs... Maybe we should
introduce new INI level that is only settable by SAPI but not changeable
later? Just brainstorming here.

Reflection export() - check if any real code is using it. Reflection
printing is kinda-sorta is the area that BC breaks may be acceptable,
since it's unlikely production code paths would depend on it, but we
need to check it. Undecided so far.

mb_strrpos - if we promised to deprecate, we may as well do it.

implode() - leave it alone, yes I know it's weird order, but messing
with it helps nobody. Yes, I know, "inconsistent". Making it
"consistent" will improve the life of exactly 0 people. Please let it be.

ezmlm_hash - undecided... it's really the niche of the niche. It also
doesn't hurt anyone, but not sure if anybody actually using it anymore.

allow_url_include - as I said, needs separate RFC. I am leaning towards
removing it, but maybe there's some use case for it...

Unbinding $this - already wrote about it, doesn't look like we have a
choice there given that what it is trying to do seems not to be
supported in PHP 8. So there may not be a point in even voting on it,
unless I misunderstand the explanation. If we need a vote, may be a good
idea to separate this one either.
-- 
Stas Malyshev
smalyshev@gmail.com
  106158
July 5, 2019 14:37 nikita.ppv@gmail.com (Nikita Popov)
On Sat, Jun 22, 2019 at 10:21 PM Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi! > > enable_dl - I am not clear what is proposed - to remove dl() > functionality in PHP 8 completely, even in CLI? Or to keep it in CLI > always on and remove the directive? > My opinion: drop the directive, let the SAPI decide if dl() is possible, > with CLI keeping it. Not sure about embed though. But I guess if > somebody needs it in embed, they probably could patch it so it enables > the dl(). Not sure how easy it would be to make this per-SAPI decision > though... >
This is indeed the plan and I've clarified the RFC to say so. While doing this I double-checked the implementation and found that currently dl() is available not only in CLI and Embed, but also in CGI. I think in light of this, dropping enable_dl may make less sense, as the premise here was more of less that dl() is not available in server SAPIs anyway. Or maybe the argument has to be shifted towards "use disable_functions=dl instead, like with all other functions". Kalle, what do you think?
> The 'real' type - see no reason to touch it, it doesn't hurt anybody. > > hebrev, hebrevc, apache_request_headers, is_writeable, > convert_cyr_string, money_format, restore_include_path - leave them in > peace (argued why in another thread). Maybe legacy extension as Zeev > suggested, I'm fine with that. >
money_format should really go away due to platform support reasons. Windows has no implementation and the macos implementation appears to be buggy (memory corruption). It nearly seems like PHP is the only major remaining user of this function. Magic quotes and all related - burn with fire. Magic quotes was a
> mistake, and here my BC inner voice is not able to say anything in its > favor. > > array_key_exists(object) - fine with dropping object behavior. It does > say "array". > And btw, can we actually make it work with ArrayAccess properly? >
Not really. Despite the name ArrayAccess::offsetExists() really has isset() semantics, so there isn't anything that exposes pure existence (without null check) in the interface.
> INPUT_SESSION & INPUT_REQUEST - if they weren't implemented, drop them. > No point in keeping stuff that doesn't work. > > register_argc_argv - support making $argc/$argv always available in CLI > but not sure about the definition of CLI. Does CGI qualify? Does embed? > This worries me a bit. Same situation as in dl() - it's like we need > some ini setting that is only accessible to SAPIs... Maybe we should > introduce new INI level that is only settable by SAPI but not changeable > later? Just brainstorming here. >
Good question. Reading the code, I think the current behavior is that anything that specifies SG(request_info).argc gets proper $argv/$argc (these will be preserved and always available), while anything else gets fake $argv/$argc based on GET parameters (which will be removed and never available). A quick grep shows these SAPIs as setting SG(request_info).argc: CLI, CGI, Embed, Litespeed, phpdbg. So it's not even really a matter of CLI vs server SAPIs, just whether command line args are provided by the SAPI or not. I feel like overall this change is not really a great fit for this deprecation RFC, and we should probably just land these changes in PHP 8.
> Reflection export() - check if any real code is using it. Reflection > printing is kinda-sorta is the area that BC breaks may be acceptable, > since it's unlikely production code paths would depend on it, but we > need to check it. Undecided so far. > > mb_strrpos - if we promised to deprecate, we may as well do it. > > implode() - leave it alone, yes I know it's weird order, but messing > with it helps nobody. Yes, I know, "inconsistent". Making it > "consistent" will improve the life of exactly 0 people. Please let it be. >
I have a related question on this one: Apparently (TIL) implode() also accepts just an array, in which case glue="". Kalle, will this form also be deprecated, or does it remain? ezmlm_hash - undecided... it's really the niche of the niche. It also
> doesn't hurt anyone, but not sure if anybody actually using it anymore. > > allow_url_include - as I said, needs separate RFC. I am leaning towards > removing it, but maybe there's some use case for it... > > Unbinding $this - already wrote about it, doesn't look like we have a > choice there given that what it is trying to do seems not to be > supported in PHP 8. So there may not be a point in even voting on it, > unless I misunderstand the explanation. If we need a vote, may be a good > idea to separate this one either. >
To be clear: We can (and currently do) support this in PHP 8. It's just a question of performance. Thanks to the removal of calling static methods non-statically, we can now remove the NULL check that occurs on every single property acces, method call, etc. If we do, it will currently come at the cost of a separate opcode for each $this access in a closure. If we remove the ability to unbind $this, we could do this without imposing a cost in any common scenario (the only one would be when using $this outside a class, e.g. in templates, which is not important). Nikita
  106163
July 8, 2019 10:27 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Jul 5, 2019 at 4:37 PM Nikita Popov ppv@gmail.com> wrote:

> On Sat, Jun 22, 2019 at 10:21 PM Stanislav Malyshev <smalyshev@gmail.com> > wrote: > >> Hi! >> >> enable_dl - I am not clear what is proposed - to remove dl() >> functionality in PHP 8 completely, even in CLI? Or to keep it in CLI >> always on and remove the directive? >> My opinion: drop the directive, let the SAPI decide if dl() is possible, >> with CLI keeping it. Not sure about embed though. But I guess if >> somebody needs it in embed, they probably could patch it so it enables >> the dl(). Not sure how easy it would be to make this per-SAPI decision >> though... >> > > This is indeed the plan and I've clarified the RFC to say so. While doing > this I double-checked the implementation and found that currently dl() is > available not only in CLI and Embed, but also in CGI. > > I think in light of this, dropping enable_dl may make less sense, as the > premise here was more of less that dl() is not available in server SAPIs > anyway. Or maybe the argument has to be shifted towards "use > disable_functions=dl instead, like with all other functions". > > Kalle, what do you think? > > >> The 'real' type - see no reason to touch it, it doesn't hurt anybody. >> >> hebrev, hebrevc, apache_request_headers, is_writeable, >> convert_cyr_string, money_format, restore_include_path - leave them in >> peace (argued why in another thread). Maybe legacy extension as Zeev >> suggested, I'm fine with that. >> > > money_format should really go away due to platform support reasons. > Windows has no implementation and the macos implementation appears to be > buggy (memory corruption). It nearly seems like PHP is the only major > remaining user of this function. > > Magic quotes and all related - burn with fire. Magic quotes was a >> mistake, and here my BC inner voice is not able to say anything in its >> favor. >> >> array_key_exists(object) - fine with dropping object behavior. It does >> say "array". >> And btw, can we actually make it work with ArrayAccess properly? >> > > Not really. Despite the name ArrayAccess::offsetExists() really has > isset() semantics, so there isn't anything that exposes pure existence > (without null check) in the interface. > > >> INPUT_SESSION & INPUT_REQUEST - if they weren't implemented, drop them. >> No point in keeping stuff that doesn't work. >> >> register_argc_argv - support making $argc/$argv always available in CLI >> but not sure about the definition of CLI. Does CGI qualify? Does embed? >> This worries me a bit. Same situation as in dl() - it's like we need >> some ini setting that is only accessible to SAPIs... Maybe we should >> introduce new INI level that is only settable by SAPI but not changeable >> later? Just brainstorming here. >> > > Good question. Reading the code, I think the current behavior is that > anything that specifies SG(request_info).argc gets proper $argv/$argc > (these will be preserved and always available), while anything else gets > fake $argv/$argc based on GET parameters (which will be removed and never > available). > > A quick grep shows these SAPIs as setting SG(request_info).argc: CLI, CGI, > Embed, Litespeed, phpdbg. So it's not even really a matter of CLI vs server > SAPIs, just whether command line args are provided by the SAPI or not. > > I feel like overall this change is not really a great fit for this > deprecation RFC, and we should probably just land these changes in PHP 8. > > >> Reflection export() - check if any real code is using it. Reflection >> printing is kinda-sorta is the area that BC breaks may be acceptable, >> since it's unlikely production code paths would depend on it, but we >> need to check it. Undecided so far. >> >> mb_strrpos - if we promised to deprecate, we may as well do it. >> >> implode() - leave it alone, yes I know it's weird order, but messing >> with it helps nobody. Yes, I know, "inconsistent". Making it >> "consistent" will improve the life of exactly 0 people. Please let it be. >> > > I have a related question on this one: Apparently (TIL) implode() also > accepts just an array, in which case glue="". Kalle, will this form also be > deprecated, or does it remain? > > ezmlm_hash - undecided... it's really the niche of the niche. It also >> doesn't hurt anyone, but not sure if anybody actually using it anymore. >> >> allow_url_include - as I said, needs separate RFC. I am leaning towards >> removing it, but maybe there's some use case for it... >> >> Unbinding $this - already wrote about it, doesn't look like we have a >> choice there given that what it is trying to do seems not to be >> supported in PHP 8. So there may not be a point in even voting on it, >> unless I misunderstand the explanation. If we need a vote, may be a good >> idea to separate this one either. >> > > To be clear: We can (and currently do) support this in PHP 8. It's just a > question of performance. Thanks to the removal of calling static methods > non-statically, we can now remove the NULL check that occurs on every > single property acces, method call, etc. If we do, it will currently come > at the cost of a separate opcode for each $this access in a closure. If we > remove the ability to unbind $this, we could do this without imposing a > cost in any common scenario (the only one would be when using $this outside > a class, e.g. in templates, which is not important). > > Nikita >
I have now made the following changes to the RFC: * Removed enable_dl deprecation. The fact that dl() is currently available by default on CGI, which is a server SAPI, makes this more dicey and needs more careful consideration. As this RFC needs to go to vote today, I'm going with the conservative option of dropping it from the RFC. * Removed register_argc_argv change from the RFC. This was not really a deprecation, so does not belong here. We'll likely just want to make the necessary changes in PHP 8. * Removed the INPUT_SESSION + INPUT_REQUEST deprecations. These have been warning since forever, so going through an additional deprecation phase makes no sense. I went ahead and removed them in PHP 8. * For the deprecation of implode() with inverted parameter order, explicitly point out that the single-argument form is not deprecated. * Various text improvements that do not change the content of the RFC. I will start voting on this RFC later today so we make feature freeze. Nikita
  106165
July 8, 2019 11:55 zeev@php.net (Zeev Suraski)
On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov ppv@gmail.com> wrote:

> I have now made the following changes to the RFC: > > * Removed enable_dl deprecation. The fact that dl() is currently available > by default on CGI, which is a server SAPI, makes this more dicey and needs > more careful consideration. As this RFC needs to go to vote today, I'm > going with the conservative option of dropping it from the RFC. > * Removed register_argc_argv change from the RFC. This was not really a > deprecation, so does not belong here. We'll likely just want to make the > necessary changes in PHP 8. > * Removed the INPUT_SESSION + INPUT_REQUEST deprecations. These have been > warning since forever, so going through an additional deprecation phase > makes no sense. I went ahead and removed them in PHP 8. > * For the deprecation of implode() with inverted parameter order, > explicitly point out that the single-argument form is not deprecated. > * Various text improvements that do not change the content of the RFC. > > I will start voting on this RFC later today so we make feature freeze. >
Nikita, Kalle, None of my feedback was even responded to. There's something fundamentally flawed in the way deprecations are being treated. If there's no compelling case to deprecate, we shouldn't deprecate - it's that simple. Someone's (or even many people's) opinion about the standard library is not a compelling reason. That can be a reason not to add something new - but absolutely not to remove existing functionality and break users' code. convert_cyr_string(), hebrev() and hebrevc() shouldn't even be considered for deprecation. They don't clear the most basic requirement for deprecation - which is having some sort of negative impact to keeping them / positive impact from removing them. There is none. It shouldn't even be up for a vote. is_writeable() should also be removed from the list as contrary to the premise of the RFC, it is not a spelling mistake ( https://en.wiktionary.org/wiki/writeable / https://www.dictionary.com/browse/writeable). Even if it was - it's hardly sufficient enough a reason to deprecate it. There's zero, absolute zero upside from deprecating it, so it doesn't clear the basic requirement for deprecation. This one is probably the least important one from the list since the fix is easy (unlike the ones above - where it's anywhere between a small and very big headache). Still, it's based on a bogus premise and there's simply no reason to do it. Why are we proactively making the lives of users more difficult for literally no gain at all? Zeev
  106167
July 8, 2019 12:38 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jul 8, 2019 at 1:55 PM Zeev Suraski <zeev@php.net> wrote:

> > > On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov ppv@gmail.com> wrote: > >> I have now made the following changes to the RFC: >> >> * Removed enable_dl deprecation. The fact that dl() is currently >> available >> by default on CGI, which is a server SAPI, makes this more dicey and needs >> more careful consideration. As this RFC needs to go to vote today, I'm >> going with the conservative option of dropping it from the RFC. >> * Removed register_argc_argv change from the RFC. This was not really a >> deprecation, so does not belong here. We'll likely just want to make the >> necessary changes in PHP 8. >> * Removed the INPUT_SESSION + INPUT_REQUEST deprecations. These have been >> warning since forever, so going through an additional deprecation phase >> makes no sense. I went ahead and removed them in PHP 8. >> * For the deprecation of implode() with inverted parameter order, >> explicitly point out that the single-argument form is not deprecated. >> * Various text improvements that do not change the content of the RFC. >> >> I will start voting on this RFC later today so we make feature freeze. >> > > Nikita, Kalle, > > None of my feedback was even responded to. > > There's something fundamentally flawed in the way deprecations are being > treated. If there's no compelling case to deprecate, we shouldn't > deprecate - it's that simple. Someone's (or even many people's) opinion > about the standard library is not a compelling reason. That can be a > reason not to add something new - but absolutely not to remove existing > functionality and break users' code. > > convert_cyr_string(), hebrev() and hebrevc() shouldn't even be considered > for deprecation. They don't clear the most basic requirement for > deprecation - which is having some sort of negative impact to keeping them > / positive impact from removing them. There is none. It shouldn't even be > up for a vote. >
I've read your feedback, but didn't feel that a response would be productive. There's a difference in philosophy here that we have already discussed many times in the past, and I don't think discussing it one more time will change things. There are broadly two reasons to deprecate: The first is to remove technical debt in php-src itself. The second is to discourage bad practice and encourage migration to better alternatives. You clearly do not see value in the latter, and I can certainly see where you're coming from with that, but please let people make their own value judgement here, rather than saying that it "shouldn't even be considered". is_writeable() should also be removed from the list as contrary to the
> premise of the RFC, it is not a spelling mistake ( > https://en.wiktionary.org/wiki/writeable / > https://www.dictionary.com/browse/writeable). Even if it was - it's > hardly sufficient enough a reason to deprecate it. There's zero, absolute > zero upside from deprecating it, so it doesn't clear the basic requirement > for deprecation. This one is probably the least important one from the > list since the fix is easy (unlike the ones above - where it's anywhere > between a small and very big headache). Still, it's based on a bogus > premise and there's simply no reason to do it. >
I went ahead and dropped this from the RFC. Quite a few people have expressed concerns about this particular deprecation -- it almost seems like a religious question... Nikita
  106173
July 8, 2019 14:01 zeev@php.net (Zeev Suraski)
On Mon, Jul 8, 2019 at 3:38 PM Nikita Popov ppv@gmail.com> wrote:

> On Mon, Jul 8, 2019 at 1:55 PM Zeev Suraski <zeev@php.net> wrote: > >> >> >> On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov ppv@gmail.com> wrote: >> >>> I have now made the following changes to the RFC: >>> >>> * Removed enable_dl deprecation. The fact that dl() is currently >>> available >>> by default on CGI, which is a server SAPI, makes this more dicey and >>> needs >>> more careful consideration. As this RFC needs to go to vote today, I'm >>> going with the conservative option of dropping it from the RFC. >>> * Removed register_argc_argv change from the RFC. This was not really a >>> deprecation, so does not belong here. We'll likely just want to make the >>> necessary changes in PHP 8. >>> * Removed the INPUT_SESSION + INPUT_REQUEST deprecations. These have >>> been >>> warning since forever, so going through an additional deprecation phase >>> makes no sense. I went ahead and removed them in PHP 8. >>> * For the deprecation of implode() with inverted parameter order, >>> explicitly point out that the single-argument form is not deprecated. >>> * Various text improvements that do not change the content of the RFC. >>> >>> I will start voting on this RFC later today so we make feature freeze. >>> >> >> Nikita, Kalle, >> >> None of my feedback was even responded to. >> >> There's something fundamentally flawed in the way deprecations are being >> treated. If there's no compelling case to deprecate, we shouldn't >> deprecate - it's that simple. Someone's (or even many people's) opinion >> about the standard library is not a compelling reason. That can be a >> reason not to add something new - but absolutely not to remove existing >> functionality and break users' code. >> >> convert_cyr_string(), hebrev() and hebrevc() shouldn't even be considered >> for deprecation. They don't clear the most basic requirement for >> deprecation - which is having some sort of negative impact to keeping them >> / positive impact from removing them. There is none. It shouldn't even be >> up for a vote. >> > > I've read your feedback, but didn't feel that a response would be > productive. There's a difference in philosophy here that we have already > discussed many times in the past, and I don't think discussing it one more > time will change things. >
Some of my feedback could be attributed to different philosophies, but certainly not all of it. I have to say, both in the previous time you mentioned that 'a response would not be productive' and this time around, even if that's not what you meant (and I certainly hope it wasn't) - I found it quite insulting. I didn't object to the entire RFC, provided both focused feedback as well as constructive (IMHO) proposals to how we can potentially create a situation where both 'camps' are happy. Is it really sensible to simply ignore it? Should we move from RFC's to PDC's (Please Don't Comment)? There are broadly two reasons to deprecate: The first is to remove
> technical debt in php-src itself. The second is to discourage bad practice > and encourage migration to better alternatives. You clearly do not see > value in the latter, and I can certainly see where you're coming from with > that, but please let people make their own value judgement here, rather > than saying that it "shouldn't even be considered". >
I absolutely do see value in discouraging bad practice. I was one of the key supporters of deprecating safe_mode, and if I recall correctly also magic_quotes - two of the worst practices in PHP's history that were *huge* compatibility breaks. Andi and I reinvented the PHP object model at a huge compatibility breakage cost, because it was the right thing to do and fostered much better development practices. So please, don't characterize my view as 'clearly not seeing value in discouraging bad practice'. A better way to describe it is that my bar for defining 'bad practice' is slightly higher than the virtually non-existent one used for some of the deprecation proposals in the RFC. Deprecations, unlike introduction of new features - aren't a case where we can simply let "people make their own judgement". That makes sense when introducing new features. But when deprecating feature - this is a surefire recipe for a tyranny of the majority. That's exactly why the Project's DNA should be respected, instead of trying to push anything and everything for a vote. True, it's not explicitly spelled out as a ground rule, but it's very strongly implied here, in the voting RFC: "Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible the purpose of the vote is to ensure that there's strong support for the proposed feature". Obviously, 'for the most part' is up for interpretation - but the intention is clear - breaking things should only come if there are substantial, tangible gains. That's how it's always been, and that's how it should continue to be. We can perhaps turn it into a harsh requirement (such as 95% vote), or we can stick with only pushing forward proposals that bring real, tangible value. I think even you would agree that this isn't the case for at least some of of the deprecation proposals, and as such, I very much stand by my position that the deprecations in the list that bring virtually no gains other than 'we think people are better off doing it differently' should simply not be voted on. Moreover, at least in on case here - there's simply no objectively (or even subjectively) better way of doing things - the RFC is simply stating that "people should not be doing this at all in 2019", even though the authors are clearly not domain experts in that topic (please pardon my assumption and correct me if I'm wrong). I'm not aware of any better alternative to using hebrev() in a context where it's needed. Both Stas and I provided examples/indicators that it is in fact, still being used - even if it's not as common as it was in 1998 and probably used mostly outside the context of HTML (which, by the way, makes the whole W3C quote about what should or shouldn't be used in HTML irrelevant).
> is_writeable() should also be removed from the list as contrary to the >> premise of the RFC, it is not a spelling mistake ( >> https://en.wiktionary.org/wiki/writeable / >> https://www.dictionary.com/browse/writeable). Even if it was - it's >> hardly sufficient enough a reason to deprecate it. There's zero, absolute >> zero upside from deprecating it, so it doesn't clear the basic requirement >> for deprecation. This one is probably the least important one from the >> list since the fix is easy (unlike the ones above - where it's anywhere >> between a small and very big headache). Still, it's based on a bogus >> premise and there's simply no reason to do it. >> > > I went ahead and dropped this from the RFC. Quite a few people have > expressed concerns about this particular deprecation -- it almost seems > like a religious question... >
Thanks, although it is indeed the least problematic deprecation on the list in terms of the headache involved in dealing with it. Zeev
  106177
July 8, 2019 14:37 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jul 8, 2019 at 4:01 PM Zeev Suraski <zeev@php.net> wrote:

> > > On Mon, Jul 8, 2019 at 3:38 PM Nikita Popov ppv@gmail.com> wrote: > >> On Mon, Jul 8, 2019 at 1:55 PM Zeev Suraski <zeev@php.net> wrote: >> >>> >>> >>> On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov ppv@gmail.com> >>> wrote: >>> >>>> I have now made the following changes to the RFC: >>>> >>>> * Removed enable_dl deprecation. The fact that dl() is currently >>>> available >>>> by default on CGI, which is a server SAPI, makes this more dicey and >>>> needs >>>> more careful consideration. As this RFC needs to go to vote today, I'm >>>> going with the conservative option of dropping it from the RFC. >>>> * Removed register_argc_argv change from the RFC. This was not really a >>>> deprecation, so does not belong here. We'll likely just want to make the >>>> necessary changes in PHP 8. >>>> * Removed the INPUT_SESSION + INPUT_REQUEST deprecations. These have >>>> been >>>> warning since forever, so going through an additional deprecation phase >>>> makes no sense. I went ahead and removed them in PHP 8. >>>> * For the deprecation of implode() with inverted parameter order, >>>> explicitly point out that the single-argument form is not deprecated. >>>> * Various text improvements that do not change the content of the RFC. >>>> >>>> I will start voting on this RFC later today so we make feature freeze. >>>> >>> >>> Nikita, Kalle, >>> >>> None of my feedback was even responded to. >>> >>> There's something fundamentally flawed in the way deprecations are being >>> treated. If there's no compelling case to deprecate, we shouldn't >>> deprecate - it's that simple. Someone's (or even many people's) opinion >>> about the standard library is not a compelling reason. That can be a >>> reason not to add something new - but absolutely not to remove existing >>> functionality and break users' code. >>> >>> convert_cyr_string(), hebrev() and hebrevc() shouldn't even be >>> considered for deprecation. They don't clear the most basic requirement >>> for deprecation - which is having some sort of negative impact to keeping >>> them / positive impact from removing them. There is none. It shouldn't >>> even be up for a vote. >>> >> >> I've read your feedback, but didn't feel that a response would be >> productive. There's a difference in philosophy here that we have already >> discussed many times in the past, and I don't think discussing it one more >> time will change things. >> > > Some of my feedback could be attributed to different philosophies, but > certainly not all of it. I have to say, both in the previous time you > mentioned that 'a response would not be productive' and this time around, > even if that's not what you meant (and I certainly hope it wasn't) - I > found it quite insulting. I didn't object to the entire RFC, provided both > focused feedback as well as constructive (IMHO) proposals to how we can > potentially create a situation where both 'camps' are happy. Is it really > sensible to simply ignore it? Should we move from RFC's to PDC's (Please > Don't Comment)? > > There are broadly two reasons to deprecate: The first is to remove >> technical debt in php-src itself. The second is to discourage bad practice >> and encourage migration to better alternatives. You clearly do not see >> value in the latter, and I can certainly see where you're coming from with >> that, but please let people make their own value judgement here, rather >> than saying that it "shouldn't even be considered". >> > > I absolutely do see value in discouraging bad practice. I was one of the > key supporters of deprecating safe_mode, and if I recall correctly also > magic_quotes - two of the worst practices in PHP's history that were > *huge* compatibility breaks. Andi and I reinvented the PHP object model > at a huge compatibility breakage cost, because it was the right thing to do > and fostered much better development practices. So please, don't > characterize my view as 'clearly not seeing value in discouraging bad > practice'. A better way to describe it is that my bar for defining 'bad > practice' is slightly higher than the virtually non-existent one used for > some of the deprecation proposals in the RFC. > > Deprecations, unlike introduction of new features - aren't a case where we > can simply let "people make their own judgement". That makes sense when > introducing new features. But when deprecating feature - this is a > surefire recipe for a tyranny of the majority. That's exactly why the > Project's DNA should be respected, instead of trying to push anything and > everything for a vote. True, it's not explicitly spelled out as a ground > rule, but it's very strongly implied here, in the voting RFC: > "Given that changes to languages (as opposed to changes to apps or even > frameworks) are for the most part irreversible the purpose of the vote is > to ensure that there's strong support for the proposed feature". > > Obviously, 'for the most part' is up for interpretation - but the > intention is clear - breaking things should only come if there are > substantial, tangible gains. That's how it's always been, and that's how > it should continue to be. We can perhaps turn it into a harsh requirement > (such as 95% vote), or we can stick with only pushing forward proposals > that bring real, tangible value. I think even you would agree that this > isn't the case for at least some of of the deprecation proposals, and as > such, I very much stand by my position that the deprecations in the list > that bring virtually no gains other than 'we think people are better off > doing it differently' should simply not be voted on. > > Moreover, at least in on case here - there's simply no objectively (or > even subjectively) better way of doing things - the RFC is simply stating > that "people should not be doing this at all in 2019", even though the > authors are clearly not domain experts in that topic (please pardon my > assumption and correct me if I'm wrong). I'm not aware of any better > alternative to using hebrev() in a context where it's needed. Both Stas > and I provided examples/indicators that it is in fact, still being used - > even if it's not as common as it was in 1998 and probably used mostly > outside the context of HTML (which, by the way, makes the whole W3C quote > about what should or shouldn't be used in HTML irrelevant). >
I'm certainly not a domain expert in RTL languages. I'd be happy to drop hebrev() from this RFC if someone can bring forward a good technical argument as to why these functions are still necessary and where they would be used. However, and given your comment here I may have just missed this between other mail, I have not actually seen any technical argument on this topic. The only thing I found was a namedrop of "IBM i" without any explanation of the significance this has for Hebrew text or the hebrev() function. (To be clear: I'm not interested in whether it's still used, I'm interested whether it's still used *for good reason*.) Nikita
  106180
July 8, 2019 16:56 zeev@php.net (Zeev Suraski)
On Mon, Jul 8, 2019 at 5:37 PM Nikita Popov ppv@gmail.com> wrote:

> > I'm certainly not a domain expert in RTL languages. I'd be happy to drop > hebrev() from this RFC if someone can bring forward a good technical > argument as to why these functions are still necessary and where they would > be used. >
I do insist you have it backwards - you need a good technical argument as to why these functions should be removed - i.e., what negative value do they bring to the table that would be sorted out by their elimitation (which could even be "pushing people towards using something that I consider better", but even that is not available). This is key, and went completely ignored. That said:
> However, and given your comment here I may have just missed this between > other mail, I have not actually seen any technical argument on this topic.. > The only thing I found was a namedrop of "IBM i" without any explanation of > the significance this has for Hebrew text or the hebrev() function >
IBM i is not a namedrop at all. Basically, any platform that has no built-in RTL support (IBM i being one of them, there are many more) would benefit from hebrev(). As a matter of fact, I just recalled that this is even useful under Windows (I used it myself a few months ago and forgot about it) - as the Windows shell doesn't render logical Hebrew either. For instance, if you have the following files in C:\somedir: C:\somedir\ניקיטה C:\somedir\קאל (that's Nikita and Kalle) The following script: ---- https://www.dropbox.com/s/tjs8jwypmy7nvay/Hebrew%20Logical.PNG?dl=0 When fixed with hebrev(): ---- https://www.dropbox.com/s/wss5fswd9gqj5vk/Hebrew%20Visual.PNG?dl=0 I'm *almost* sure that you'd get the same results on Linux. Simply put - hebrev() is super useful for CLI apps. The fact it's nowadays thankfully uncommon for HTML to be based on visual encodings, doesn't mean visual representations have disappeared. They're still there in all sorts of legacy situations - including legacy scenarios in modern OSs (the above is from Windows 10 1903). (To be clear: I'm not interested in whether it's still used, I'm interested
> whether it's still used *for good reason*.) >
If it's still being used, it's almost definitely being used for a good reason. Nobody uses hebrev() to knock themselves out or because they take some sort of perverted pleasure out of it. They use it because they have to. And what you're proposing is taking that capability away, providing zero workarounds, and gaining absolutely nothing in the process. Why? Zeev
  106182
July 8, 2019 18:23 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jul 8, 2019 at 6:56 PM Zeev Suraski <zeev@php.net> wrote:

> > > On Mon, Jul 8, 2019 at 5:37 PM Nikita Popov ppv@gmail.com> wrote: > >> >> I'm certainly not a domain expert in RTL languages. I'd be happy to drop >> hebrev() from this RFC if someone can bring forward a good technical >> argument as to why these functions are still necessary and where they would >> be used. >> > > I do insist you have it backwards - you need a good technical argument as > to why these functions should be removed - i.e., what negative value do > they bring to the table that would be sorted out by their elimitation > (which could even be "pushing people towards using something that I > consider better", but even that is not available). This is key, and went > completely ignored. > > That said: > > >> However, and given your comment here I may have just missed this between >> other mail, I have not actually seen any technical argument on this topic. >> The only thing I found was a namedrop of "IBM i" without any explanation of >> the significance this has for Hebrew text or the hebrev() function >> > > IBM i is not a namedrop at all. Basically, any platform that has no > built-in RTL support (IBM i being one of them, there are many more) would > benefit from hebrev(). As a matter of fact, I just recalled that this is > even useful under Windows (I used it myself a few months ago and forgot > about it) - as the Windows shell doesn't render logical Hebrew either. For > instance, if you have the following files in C:\somedir: > > C:\somedir\ניקיטה > C:\somedir\קאל > > (that's Nikita and Kalle) > > The following script: > ---- > $d = opendir("c:\\somedir"); > while ($f = readdir($d)) { > print "$f\n"; > } > --- > > Would generate the following output: > https://www.dropbox.com/s/tjs8jwypmy7nvay/Hebrew%20Logical.PNG?dl=0 > > When fixed with hebrev(): > ---- > $d = opendir("c:\\somedir"); > while ($f = readdir($d)) { > print hebrev($f)."\n"; > } > --- > > It will display the correct output: > https://www.dropbox.com/s/wss5fswd9gqj5vk/Hebrew%20Visual.PNG?dl=0 > > I'm *almost* sure that you'd get the same results on Linux. > > Simply put - hebrev() is super useful for CLI apps. > > The fact it's nowadays thankfully uncommon for HTML to be based on visual > encodings, doesn't mean visual representations have disappeared. They're > still there in all sorts of legacy situations - including legacy scenarios > in modern OSs (the above is from Windows 10 1903). >
Thanks Zeev, this is exactly the kind of feedback I was looking for. As you make a case for a possible legitimate use-case, I'm dropping the hebrev() deprecation from this RFC, so that the proposal only covers hebrevc() now. (As a side note, it would be great if this kind of information also made it into the documentation for hebrev().) Nikita
  106168
July 8, 2019 12:43 thruska@cubiclesoft.com (Thomas Hruska)
On 7/8/2019 4:55 AM, Zeev Suraski wrote:
> Why are we proactively making the lives of users more difficult for > literally no gain at all? > > Zeev
Because that's what software developers tend to do when they are bored. Instead of focusing on API stability, squashing bugs and other generally mundane, boring, but rather important tasks that tend to get overlooked, they focus on what interests them personally: Cool features, re-inventing existing functionality because one tiny thing irks them but no one else, and there's even a level of jealousy, greed and possibly some malice in the mix too. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/
  106027
June 22, 2019 12:23 narf@devilix.net (Andrey Andreev)
Hi,

With regards to the array_key_exists() deprecation, the RFC currently
says nothing about things like ArrayAccess and object properties that
contain arrays. I'm sure that these are exceptions that aren't meant
to be deprecated, but can you please specify that explicitly? We all
know how little bits like that can result in awful outcomes.

Also, it's unclear to me why get_called_class() should be deprecated.
While the rest of the listed deprecations have either motivation
written for them or are self-evidently legacy functionalities that
nobody should be using today, this one seems to be just a case of
"let's not have more than one way of doing things" and I'm not really
a fan of that.

Cheers,
Andrey.
  106028
June 22, 2019 12:58 nikita.ppv@gmail.com (Nikita Popov)
On Sat, Jun 22, 2019 at 2:24 PM Andrey Andreev <narf@devilix.net> wrote:

> Hi, > > With regards to the array_key_exists() deprecation, the RFC currently > says nothing about things like ArrayAccess and object properties that > contain arrays. I'm sure that these are exceptions that aren't meant > to be deprecated, but can you please specify that explicitly? We all > know how little bits like that can result in awful outcomes. >
Thanks for bringing this up: It's a great example of why this needs to be deprecated. array_key_exists() actually has no support for ArrayAccess objects at all -- it only operates on (mangled) object properties. But just seeing the name and the fact that it doesn't error when passed an ArrayAccess object, it's quite easy to jump to the wrong conclusion. I've updated the RFC to mention this now. I don't understand what you mean by "object properties that contain arrays" though, or rather how that related to array_key_exists(). Also, it's unclear to me why get_called_class() should be deprecated.
> While the rest of the listed deprecations have either motivation > written for them or are self-evidently legacy functionalities that > nobody should be using today, this one seems to be just a case of > "let's not have more than one way of doing things" and I'm not really > a fan of that. >
Personally I agree. I don't really see a strong motivation for dropping this function. Kalle? Nikita
  106040
June 22, 2019 21:33 narf@devilix.net (Andrey Andreev)
Hi,

On Sat, Jun 22, 2019 at 3:59 PM Nikita Popov ppv@gmail.com> wrote:
> > On Sat, Jun 22, 2019 at 2:24 PM Andrey Andreev <narf@devilix.net> wrote: >> >> Hi, >> >> With regards to the array_key_exists() deprecation, the RFC currently >> says nothing about things like ArrayAccess and object properties that >> contain arrays. I'm sure that these are exceptions that aren't meant >> to be deprecated, but can you please specify that explicitly? We all >> know how little bits like that can result in awful outcomes. > > > Thanks for bringing this up: It's a great example of why this needs to be deprecated. array_key_exists() actually has no support for ArrayAccess objects at all -- it only operates on (mangled) object properties. But just seeing the name and the fact that it doesn't error when passed an ArrayAccess object, it's quite easy to jump to the wrong conclusion. I've updated the RFC to mention this now. >
Well, then I guess actually implementing ArrayAccess support should be brought up now, but other than that the updated RFC content makes much more sense now. Thank you.
> I don't understand what you mean by "object properties that contain arrays" though, or rather how that related to array_key_exists(). >
I had a minor brain fart while originally thinking about this and it's actually nothing. Sorry about that. Cheers, Andrey.
  106031
June 22, 2019 16:10 info@pieterhordijk.com (Pieter Hordijk)
> Also, it's unclear to me why get_called_class() should be deprecated. > While the rest of the listed deprecations have either motivation > written for them or are self-evidently legacy functionalities that > nobody should be using today, this one seems to be just a case of > "let's not have more than one way of doing things" and I'm not really > a fan of that.
I agree with above. When looking through the list of deprecations this one jumps out for me as being an outlier too. Maybe it should just be removed from the RFC? Pieter
  106032
June 22, 2019 16:58 nikita.ppv@gmail.com (Nikita Popov)
On Sat, Jun 22, 2019 at 6:11 PM Pieter Hordijk <info@pieterhordijk.com>
wrote:

> > > > Also, it's unclear to me why get_called_class() should be deprecated. > > While the rest of the listed deprecations have either motivation > > written for them or are self-evidently legacy functionalities that > > nobody should be using today, this one seems to be just a case of > > "let's not have more than one way of doing things" and I'm not really > > a fan of that. > > I agree with above. When looking through the list of deprecations this > one jumps out for me as being an outlier too. > > Maybe it should just be removed from the RFC?
As we all seem to agree on this one (Kalle as well), I went ahead and dropped it from the RFC. Nikita
  106171
July 8, 2019 13:41 claude.pache@gmail.com (Claude Pache)
The deprecation RFC lists `apache_request_headers()`, because it is “an Apache-specific name is also available in other SAPIs, even though it is also available under the SAPI-independent name getallheaders()”.

Have you ever thought about making a more thorough and consistent change with other similar functions, instead of just picking one particular function because it is the only one in its category that has a documented alias? In five minutes, I’m thinking of the following obvious things:

* using a less ambiguous name than `getallheaders()`, given the existence of both `apache_request_headers()` and `apache_response_headers()`;

* renaming all `apache_*()` functions that are available in other SAPI into a SAPI-independent name;

* treating all `nsapi_*()` functions as well.

—Claude
  106175
July 8, 2019 14:14 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jul 8, 2019 at 3:41 PM Claude Pache pache@gmail.com> wrote:

> The deprecation RFC lists `apache_request_headers()`, because it is “an > Apache-specific name is also available in other SAPIs, even though it is > also available under the SAPI-independent name getallheaders()”. > > Have you ever thought about making a more thorough and consistent change > with other similar functions, instead of just picking one particular > function because it is the only one in its category that has a documented > alias? In five minutes, I’m thinking of the following obvious things: > > * using a less ambiguous name than `getallheaders()`, given the existence > of both `apache_request_headers()` and `apache_response_headers()`; > > * renaming all `apache_*()` functions that are available in other SAPI > into a SAPI-independent name; > > * treating all `nsapi_*()` functions as well. >
Thanks for bringing this up. I agree with you, and have dropped apache_request_headers() from this RFC. This clearly needs a more comprehensive change. Note that nsapi no longer exists since PHP 7, but litespeed also has its own variation of these functions as well. Nikita