[RFC] Deprecations for 7.4 View as Markdown

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

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]

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

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

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

--

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

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 "writable", which is
undoubtedly a false positive."

Le 21 juin 2019 à 20:15, Bishop Bettini bishop@php.net a écrit :

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

Le 21 juin 2019 à 20:15, Bishop Bettini bishop@php.net a écrit :

On Fri, Jun 21, 2019, 13:54 Claude Pache <claude.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

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.

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

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

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 <html dir="rtl" 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

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

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 <html dir="rtl" 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

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 <html dir="rtl" 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

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 <html dir="rtl" 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

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.

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

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

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

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 <html dir="rtl" 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

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

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

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

Hi,

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.

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

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

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

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

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/

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

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

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

On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov nikita.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

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:

<?php
$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():

<?php
$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).

(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

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:

<?php
$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():

<?php
$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