[VOTE] Deprecations for PHP 8.1

  115230
June 30, 2021 09:32 nikita.ppv@gmail.com (Nikita Popov)
Hi internals,

I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The
vote closes on 2021-07-14.

This RFC is a collection of various deprecation suggestions from different
people. Each deprecation is voted separately, and should be considered on
its own merit.

Most deprecations should be uncontroversial, but there are some more
contentious ones as well: See https://externals.io/message/113657 for
additional discussion.

Regards,
Nikita
  115242
June 30, 2021 14:01 Danack@basereality.com (Dan Ackroyd)
On Wed, 30 Jun 2021 at 10:32, Nikita Popov ppv@gmail.com> wrote:
> > Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14.
Just to note, for the auto_detect_line_endings ini setting "These newlines were used by “Classic” Mac OS, a system which has been discontinued in 2001,". Although that OS may have been discontinued in 2001, I think later OS's had a tendency to create files in a 'compatibility mode'. I have encountered a user uploaded CSV file that had the old file endings as recently as ... 2011. So it's probably safe to deprecate, but only by one decade rather than two. cheers Dan Ack
  115253
July 1, 2021 12:15 pierre.php@gmail.com (Pierre Joye)
Hi Nikita,

On Wed, Jun 30, 2021, 4:32 PM Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion.
I hope the num_points do not pass. However if it does, I would like to still reconsider it for the reasons I mentioned in the discussion: support nightmare Any image will be broken if a server is not configured smoothly for prod. Unlike another script, the depreciation is not visible directly in the page. Given the amount of usages of these functions out there, I really ask to reconsider this one. Too much possible hassles for no real gain. thanks.
  115255
July 1, 2021 14:14 cmbecker69@gmx.de ("Christoph M. Becker")
On 01.07.2021 at 14:15, Pierre Joye wrote:

> Hi Nikita, > > On Wed, Jun 30, 2021, 4:32 PM Nikita Popov ppv@gmail.com> wrote: > >> Hi internals, >> >> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The >> vote closes on 2021-07-14. >> >> This RFC is a collection of various deprecation suggestions from different >> people. Each deprecation is voted separately, and should be considered on >> its own merit. >> >> Most deprecations should be uncontroversial, but there are some more >> contentious ones as well: See https://externals.io/message/113657 for >> additional discussion. > > I hope the num_points do not pass. However if it does, I would like to > still reconsider it for the reasons I mentioned in the discussion: support > nightmare > > Any image will be broken if a server is not configured smoothly for prod. > Unlike another script, the depreciation is not visible directly in the > page. Given the amount of usages of these functions out there, I really ask > to reconsider this one. Too much possible hassles for no real gain.
In my opinion, *not* having a signature like function imagepolygon( GdImage $image, array $points, int $num_points_or_color, ?int $color = null ): bool {} and the respective implementation mess, is a gain; not a huge gain, but still a real gain to me. And image generation code which relies on display_errors to catch errors is already broken. By your argument, we could not even introduce new warnings. Anyhow, fixing the deprecated code would be trivial (the RFC shows an example), and can even be automated, and I consider it not unlikely that code which runs on PHP 8 has unit-tests and/or static analysis what may catch this issue early. Christoph
  115256
July 1, 2021 14:32 pierre.php@gmail.com (Pierre Joye)
On Thu, Jul 1, 2021, 9:14 PM Christoph M. Becker <cmbecker69@gmx.de> wrote:

> On 01.07.2021 at 14:15, Pierre Joye wrote: > > > Hi Nikita, > > > > On Wed, Jun 30, 2021, 4:32 PM Nikita Popov ppv@gmail.com> wrote: > > > >> Hi internals, > >> > >> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. > The > >> vote closes on 2021-07-14. > >> > >> This RFC is a collection of various deprecation suggestions from > different > >> people. Each deprecation is voted separately, and should be considered > on > >> its own merit. > >> > >> Most deprecations should be uncontroversial, but there are some more > >> contentious ones as well: See https://externals.io/message/113657 for > >> additional discussion. > > > > I hope the num_points do not pass. However if it does, I would like to > > still reconsider it for the reasons I mentioned in the discussion: > support > > nightmare > > > > Any image will be broken if a server is not configured smoothly for > prod. > > Unlike another script, the depreciation is not visible directly in the > > page. Given the amount of usages of these functions out there, I really > ask > > to reconsider this one. Too much possible hassles for no real gain. > > In my opinion, *not* having a signature like > > function imagepolygon( > GdImage $image, > array $points, > int $num_points_or_color, > ?int $color = null > ): bool {} > > and the respective implementation mess, is a gain; not a huge gain, but > still a real gain to me. > > And image generation code which relies on display_errors to catch errors > is already broken. By your argument, we could not even introduce new > warnings. > > Anyhow, fixing the deprecated code would be trivial (the RFC shows an > example), and can even be automated, and I consider it not unlikely that > code which runs on PHP 8 has unit-tests and/or static analysis what may > catch this issue early.
The codes which will do this are not the ones I am worrying about. This is not some function never used before but anyone out there. Or something that causes pains to the engine or prevents major features to happen. This function has to be replaced, not made incompatible. best Pierre
  115289
July 5, 2021 09:42 dmitrystogov@gmail.com (Dmitry Stogov)
Return void by reference should be disabled (not deprecated)

On Wed, Jun 30, 2021 at 12:32 PM Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. > > Regards, > Nikita >
  115293
July 5, 2021 10:51 patrickallaert@php.net (Patrick ALLAERT)
Le lun. 5 juil. 2021 à 11:43, Dmitry Stogov <dmitrystogov@gmail.com> a
écrit :

> Return void by reference should be disabled (not deprecated) >
I second that.
  115291
July 5, 2021 10:15 ocramius@gmail.com (Marco Pivetta)
Hey Nikita,

On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. > > I'm totally **for** deprecating `get_*class()` implementations when called
without arguments, but I feel like many folks are voting "no" because: * there's no 1:1 migration suggestion in that section * the section states " `get_class()` is approximately the same as `self::class`", without saying what "approximately" means I can imagine that removing `get_called_class()` could also yield some engine improvements in future, as there's also less "magic information about caller scope" to be retained. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  115292
July 5, 2021 10:46 patrickallaert@php.net (Patrick ALLAERT)
Le mer. 30 juin 2021 à 11:32, Nikita Popov ppv@gmail.com> a écrit :

> Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. The > vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. > > Regards, > Nikita >
For reasons that Nikita expressed ( https://externals.io/message/113657#114033) in the discussion thread, I wish strftime() and gmtstrftime() would be deprecated, BUT NOT removed in PHP 9.0. Did we ever deprecated something without the immediate intention of removing it?
  115294
July 5, 2021 11:14 rowan.collins@gmail.com (Rowan Tommins)
On 05/07/2021 11:46, Patrick ALLAERT wrote:
> Did we ever deprecated something without the immediate intention of > removing it?
What would that even mean? Surely a deprecation, by definition, is a notice that something is going to be removed. There used to be an E_STRICT category, which expressed a rather vague "you probably shouldn't do this", but I'm not sure who it really helped. If you want to encourage people to use alternatives to strftime() but not remove it, here are some more productive steps: * Improve the strftime() documentation to point out what those alternatives are, and why they're better * Improve the documentation of those alternatives with examples of the things that strftime() is commonly used for * Improve those alternatives themselves so that they're as easy to use as strftime() Regards, -- Rowan Tommins [IMSoP]
  115295
July 5, 2021 11:39 mike@newclarity.net (Mike Schinkel)
> On Jul 5, 2021, at 7:14 AM, Rowan Tommins collins@gmail.com> wrote: > > On 05/07/2021 11:46, Patrick ALLAERT wrote: >> Did we ever deprecated something without the immediate intention of >> removing it? > > > What would that even mean?
It would mean that although the functions are available and allowed, they are not recommended[1].
> Surely a deprecation, by definition, is a notice that something is going to be removed.
I know that you, and others on this list, have chosen to define deprecation as including removal, but that is actually not the accepted definition on the web, nor is it in any way a requirement, it is just your preference. Indirectly from Wikipedia and voted as the top answer on StackOverflow here[2] (emphasis MINE): "deprecation is a status applied to software features to indicate that they should be avoided, typically because they have been superseded. Although deprecated features remain in the software, their use may raise warning messages recommending alternative practices, and deprecation MAY indicate that the feature will be removed in the future." So I am arguing for the legitimacy of retaining "deprecated" features if their removal would cause significant BC breakage, I'm not just trying to be a pendant. -Mike [1] https://whatis.techtarget.com/definition/deprecated [2] https://stackoverflow.com/questions/8111774/deprecated-meaning
  115297
July 5, 2021 12:03 guilliam.xavier@gmail.com (Guilliam Xavier)
On Mon, Jul 5, 2021 at 1:39 PM Mike Schinkel <mike@newclarity.net> wrote:

> > On Jul 5, 2021, at 7:14 AM, Rowan Tommins collins@gmail.com> > wrote: > > > > On 05/07/2021 11:46, Patrick ALLAERT wrote: > >> Did we ever deprecated something without the immediate intention of > >> removing it? > > > > > > What would that even mean? > > It would mean that although the functions are available and allowed, they > are not recommended[1]. > > > > Surely a deprecation, by definition, is a notice that something is going > to be removed. > > I know that you, and others on this list, have chosen to define > deprecation as including removal, but that is actually not the accepted > definition on the web, nor is it in any way a requirement, it is just your > preference. > > Indirectly from Wikipedia and voted as the top answer on StackOverflow > here[2] (emphasis MINE): > > "deprecation is a status applied to software features to indicate that > they should be avoided, typically because they have been superseded. > Although deprecated features remain in the software, their use may raise > warning messages recommending alternative practices, and deprecation MAY > indicate that the feature will be removed in the future." > > So I am arguing for the legitimacy of retaining "deprecated" features if > their removal would cause significant BC breakage, I'm not just trying to > be a pendant. > > -Mike > [1] https://whatis.techtarget.com/definition/deprecated > [2] https://stackoverflow.com/questions/8111774/deprecated-meaning >
Hi Mike, Your links speak *in general*. However this is *specifically for PHP*: https://www.php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-deprecated-error (*emphasis* mine) E_DEPRECATED: Run-time notices. Enable this to receive warnings about code that *will not work in future versions*. As for "significant BC breakage", isn't that what major versions are for? (and with the current release plan, 9.0 would be for end 2025, i.e. 4 years after 8.1) Regards, -- Guilliam Xavier
  115298
July 5, 2021 12:05 george.banyard@gmail.com ("G. P. B.")
On Mon, 5 Jul 2021 at 13:39, Mike Schinkel <mike@newclarity.net> wrote:

> > On Jul 5, 2021, at 7:14 AM, Rowan Tommins collins@gmail.com> > wrote: > > > > On 05/07/2021 11:46, Patrick ALLAERT wrote: > >> Did we ever deprecated something without the immediate intention of > >> removing it? > > > > > > What would that even mean? > > It would mean that although the functions are available and allowed, they > are not recommended[1]. > > > > Surely a deprecation, by definition, is a notice that something is going > to be removed. > > I know that you, and others on this list, have chosen to define > deprecation as including removal, but that is actually not the accepted > definition on the web, nor is it in any way a requirement, it is just your > preference. > > Indirectly from Wikipedia and voted as the top answer on StackOverflow > here[2] (emphasis MINE): > > "deprecation is a status applied to software features to indicate that > they should be avoided, typically because they have been superseded. > Although deprecated features remain in the software, their use may raise > warning messages recommending alternative practices, and deprecation MAY > indicate that the feature will be removed in the future." > > So I am arguing for the legitimacy of retaining "deprecated" features if > their removal would cause significant BC breakage, I'm not just trying to > be a pendant. > > -Mike > [1] https://whatis.techtarget.com/definition/deprecated > [2] https://stackoverflow.com/questions/8111774/deprecated-meaning >
For the PHP project deprecation means a future removal, I'm pretty sure this is an agreed policy for the project. E_STRICT was like Rowan said used for cases of "well you should probably not do this but we'll accept it", and this category has been removed. Now if you truly want this definition of "deprecation" can I bring forward again to "deprecate" short tags, using 'var' for object properties, all of the SPL data structures, a bunch of extensions, using locales, and maybe to be fancy emit one when you don't use a visibility modifier on object methods/properties/constants, heck why not even one for not using a typed property now that we got mixed and union types. As you can see this opens the door to kinda everything being marked as deprecated just to ensure another discussion needs to be held for a removal. The policy of X being deprecated means it's going to be removed is very clear for end users who don't need to scramble as to whether or not this deprecation leads to a removal or not. Best regards, George P. Banyard
  115300
July 5, 2021 12:16 rowan.collins@gmail.com (Rowan Tommins)
On 05/07/2021 12:39, Mike Schinkel wrote:
> know that you, and others on this list, have chosen to define deprecation as including removal, but that is actually not the accepted definition on the web, nor is it in any way a requirement, it is just your preference.
I stand corrected, I had not encountered contexts where it was defined differently. To be clear, I don't think contrasting "accepted definition" against "my preference" is quite right here; there are plenty of places that document the definition I am familiar with, e.g. * Foldoc (taken from the Jargon File): http://foldoc.org/deprecated * Wiktionary: https://en.wiktionary.org/wiki/deprecated Removal is also specifically mentioned in official documentation for plenty of PHP projects, e.g. * The description of the "@deprecated" tag in PhpDocumentor : https://docs.phpdoc.org/3.0/guide/references/phpdoc/tags/deprecated.html * The general migration guide for Symfony : https://symfony.com/doc/current/setup/upgrade_major.html#make-your-code-deprecation-free * The Drupal Core deprecation policy: https://www.drupal.org/about/core/policies/core-change-policies/drupal-core-deprecation-policy More directly relevant, the PHP manual at https://www.php.net/manual/en/errorfunc.constants.php currently describes E_DEPRECATED as: > Run-time notices. Enable this to receive warnings about code that will not work in future versions. Obviously, that could be changed to also include "features that are strongly discouraged but not currently planned for removal", but I'm still not convinced that that would be a useful change. If we can create and document a good alternative for strftime(), then why *not* mark it for future removal. And if we can't provide that alternative, what use is there in notices discouraging it? Regards, -- Rowan Tommins [IMSoP]
  115307
July 5, 2021 23:03 mike@newclarity.net (Mike Schinkel)
Replying in one long email to all three who replied to me:


> On Jul 5, 2021, at 8:03 AM, Guilliam Xavier xavier@gmail.com> wrote: > Hi Mike, > > Your links speak *in general*. However this is *specifically for PHP*: https://www.php.net/manual/en/errorfunc.constants.php#errorfunc.constants.errorlevels.e-deprecated-error (*emphasis* mine) > > E_DEPRECATED: Run-time notices. Enable this to receive warnings about code that *will not work in future versions*.
1. In general (no pun intended), is it a good idea for PHP to take a general concept and redefine its meaning? (Rhetorical question.) 2. That link you provided speaks of not working in future versions. That future version could be 5 major versions from now, doesn't have to be next version. 3. And most importantly, the content on that page is not written in immutable stone. It could just as easily be updated to say the following, assuming that an agreement is made to do so: "Enable this to receive warnings about code constructs that are discouraged and MAY not work in future versions, so best for developers to no longer depend on it."
> As for "significant BC breakage", isn't that what major versions are for? (and with the current release plan, 9.0 would be for end 2025, i.e. 4 years after 8.1)
They can be, but AFAIK there is no immutable principle in software that deprecated versions must be removed in the next major version. Doing so or not doing is simply a choice, a decision about what is in the best interest of the software and its user base. And unless I misunderstand, nothing about the PHP project is immutable that cannot be changed by consensus and/or an RFC vote. So I am simply making the argument that this restrictive idea that deprecations *must* result in removal in the next major version can do more harm than good in selected cases. Being restrictive in our view of deprecation means we create BC-breaked changes when we really don't have to, and more importantly it means we do not signal that certain practices are to be discouraged when we could. Imagine if we decided to deprecated global variables and instead encourage DI and/or static variables in classes? IF we could deprecate global without removal, I would be 100% for deprecating global. But given the current restrictive interpretation promoted by some, we should all be 0% for deprecating global.
> On Jul 5, 2021, at 8:05 AM, G. P. B. banyard@gmail.com> wrote: > > For the PHP project deprecation means a future removal, I'm pretty sure this is an agreed policy for the project.
Can you point me to where this has been definitely agreed in the past? An RFC ideally? (Honest question.) There is this[1] but it only says functions will usually be completely removed "Later" and not "next major version." "Later" could be 5 versions later. There is this[2], but it makes no mention of when, nor was it ever voted on. [1] https://wiki.php.net/rfc/deprecated-modifier [2] https://wiki.php.net/rfc/deprecated_attribute
> E_STRICT was like Rowan said used for cases of "well you should probably not do this but we'll accept it", > and this category has been removed.
But the E_STRICT constant was not removed. (Ironically?) The motivation was "to simplify our error model and resolve the currently unclear role of strict standards notices." So as I read it[3] we are talking apples (policy) and oranges (simplify error model/improve clarity) [3] https://wiki.php.net/rfc/reclassify_e_strict
> Now if you truly want this definition of "deprecation" can I bring forward again to "deprecate" short tags, using 'var' for object properties, all of the SPL data structures, a bunch of extensions, using locales, and maybe to be fancy emit one when you don't use a visibility modifier on object methods/properties/constants, heck why not even one for not using a typed property now that we got mixed and union types.
I would be 1000% for ALL of those. Bring them on, PLEASE. But since you wrote that I assume you think that would be a bad idea. Why?
> As you can see this opens the door to kinda everything being marked as deprecated just to ensure another discussion needs to be held for a removal.
Yes, it opens the door for doing a lot of good for PHP, IMO.
> The policy of X being deprecated means it's going to be removed is very clear for end users who don't need to scramble as to whether or not this deprecation leads to a removal or not.
In all my years working with other developers, I have never witnessed anyone "scramble" to determine if deprecation means removal. Deprecation has a pretty clear meaning to most developers I know. It simply means "not recommended." If a developer uses a deprecated feature, they are "doing it wrong." BUT, the project owner who has existing code isn't doing it wrong to want to continue to run their software without having to invest new money into refactoring because of a function removal. Unless there is a compelling reason such as security concern they should not have to spend that developer money just to use the latest version of PHP. OTOH developers would benefit from being signaled to stop using practices when there is a consensus they practices are not good even if the "bad" functionally cannot be removed in the near future.
> On Jul 5, 2021, at 8:16 AM, Rowan Tommins collins@gmail.com> wrote: > To be clear, I don't think contrasting "accepted definition" against "my preference" is quite right here; there are plenty of places that document the definition I am familiar with, e.g.
Let me clarify. When I said "your preference" I was not trying to target you, I was using "your" collectively to convey the preferences of all who prefer that interpretation. And my assumption is the people who wrote the following also had a preference for the same interpretation. But since you bring them up:
> * Foldoc (taken from the Jargon File): http://foldoc.org/deprecated
"Deprecated features can, unfortunately, linger on for many years." (Note it does not say deprecation means "must be removed in next major version.") "Said of a function or feature planned to be phased out, but still available for use." (Note it says plans do be phased out but "still available," and does not establish any time metric for removal.")
> Removal is also specifically mentioned in official documentation for plenty of PHP projects, e.g. > * The description of the "@deprecated" tag in PhpDocumentor : https://docs.phpdoc.org/3.0/guide/references/phpdoc/tags/deprecated.html
"The @deprecated tag declares that the associated Structural Element(s) will be removed in a future version" (Note it does not specify *which* future version. As written, it could mean 5 majors versions from now.) "When a new API is added, the old API will be deprecated... it will usually be removed in the next major version." (Note it says "usually," not "must" which implies that at times there are good reasons *not* to remove.)
> * The general migration guide for Symfony : https://symfony.com/doc/current/setup/upgrade_major.html#make-your-code-deprecation-free
"When the major version is released (e.g. 5.0.0), all deprecated features and functionality are removed." (This is the only one that matches your interpretation. Which is not surprising as Symfony itself is the most draconian of well-known PHP frameworks. Should PHP really be as draconian as its most draconian framework?)
> More directly relevant, the PHP manual at https://www.php.net/manual/en/errorfunc.constants.php currently describes E_DEPRECATED as: > > Run-time notices. Enable this to receive warnings about code that will not work in future versions.
As I said above, which future version? It does not state "the next major version." Besides, as I also said above, this could easily be clarified to provide an option assuming we developed a consensus on the topic.
> Obviously, that could be changed to also include "features that are strongly discouraged but not currently planned for removal", but I'm still not convinced that that would be a useful change.
I am not advocating that. I am advocating we should consider making it: "features that are strongly discouraged will *probably* be removed in the next major version, but in some cases may be retained for one or more major versions."
> If we can create and document a good alternative for strftime(), then why *not* mark it for future removal. And if we can't provide that alternative, what use is there in notices discouraging it?
I have no opinion pro or con on whether or not strftime() should be removed because I don't often use it so I don't have any idea how many BC breaks that it will entail. Instead I replied because your email strongly implied (stated?) that "deprecation required removal" and I think that position is ultimately harmful to the language evolution because it keeps of from deprecating things that we should discourage but that are too widely used to remove. -Mike P.S. I am not going to propose we have an RFC to establish a policy here, but if someone with experience knowing what is and is not appropriate for RFCs proposed I would definitely be happy to see the question getting resolved, pro OR con. P.P.S. And if it was an RFC I think the vote would need to be 51% vs. 2/3rd because it is a binary decision to clarify a policy, not a change to existing code. There is no definitive precedent to change that was ever voted on (unless I am wrong and there was an RFC on this topic?)
  115310
July 6, 2021 08:24 rowan.collins@gmail.com (Rowan Tommins)
Hi Mike,


> Instead I replied because your email strongly implied (stated?) that "deprecation required removal"
I stand by that interpretation, which while not universal is very widely used, and I think is more useful than a general hint at "bad practice". You spend most of your e-mail seeming to argue against it, and then seem to say that actually you do agree with it after all, and all you're saying is that sometimes the deprecation period should be longer:
> I am not advocating that. I am advocating we should consider making it: > > "features that are strongly discouraged will*probably* be removed in the next major version, but in some cases may be retained for one or more major versions."
I'm totally OK with that. I do think that there should be a clear *plan* for removing each deprecated feature, though. That plan might be "deprecate in 8.1, and examine prior to 9.0 whether usage has dropped / the alternatives are mature / etc". It might flat out be "deprecate in 8.1, but don't remove until 10.0". Otherwise, the message becomes "this feature is kind of bad, and at some point we might decide to drop it without further notice, but actually we might not, so no hurry to remove it", which I just think isn't that helpful. Regards, -- Rowan Tommins [IMSoP]
  115319
July 6, 2021 12:24 jakob@givoni.dk (Jakob Givoni)
On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins collins@gmail.com> wrote:
> > Hi Mike, > > > > Instead I replied because your email strongly implied (stated?) that "deprecation required removal" > > I stand by that interpretation, which while not universal is very widely > used, and I think is more useful than a general hint at "bad practice". > > You spend most of your e-mail seeming to argue against it, and then seem > to say that actually you do agree with it after all, and all you're > saying is that sometimes the deprecation period should be longer: > > > > I am not advocating that. I am advocating we should consider making it: > > > > "features that are strongly discouraged will*probably* be removed in the next major version, but in some cases may be retained for one or more major versions." > > I'm totally OK with that. > > I do think that there should be a clear *plan* for removing each > deprecated feature, though. That plan might be "deprecate in 8.1, and > examine prior to 9.0 whether usage has dropped / the alternatives are > mature / etc". It might flat out be "deprecate in 8.1, but don't remove > until 10.0". > > Otherwise, the message becomes "this feature is kind of bad, and at some > point we might decide to drop it without further notice, but actually we > might not, so no hurry to remove it", which I just think isn't that helpful. >
I think it would be very helpful. I would have loved to know that FILTER_SANITIZE_STRING was not considered a good choice when I recently researched how to improve an issue. Deprecation without a fixed removal version is better than no deprecation (because removal version was not agreed on). Actually I agree with everything that Mike said previously and I strongly suggest a policy that looks like this: Deprecation means no longer encouraged (strongly) and might be removed in a future (major) version. Before every new major version, review all deprecated features/usages and decide with a simple RFC if each of them should be removed, reviewing the current usage level and migration paths. Best, Jakob
  115321
July 6, 2021 13:30 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Jul 6, 2021 at 2:25 PM Jakob Givoni <jakob@givoni.dk> wrote:

> On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins collins@gmail.com> > wrote: > > > > Hi Mike, > > > > > > > Instead I replied because your email strongly implied (stated?) that > "deprecation required removal" > > > > I stand by that interpretation, which while not universal is very widely > > used, and I think is more useful than a general hint at "bad practice". > > > > You spend most of your e-mail seeming to argue against it, and then seem > > to say that actually you do agree with it after all, and all you're > > saying is that sometimes the deprecation period should be longer: > > > > > > > I am not advocating that. I am advocating we should consider making > it: > > > > > > "features that are strongly discouraged will*probably* be removed in > the next major version, but in some cases may be retained for one or more > major versions." > > > > I'm totally OK with that. > > > > I do think that there should be a clear *plan* for removing each > > deprecated feature, though. That plan might be "deprecate in 8.1, and > > examine prior to 9.0 whether usage has dropped / the alternatives are > > mature / etc". It might flat out be "deprecate in 8.1, but don't remove > > until 10.0". > > > > Otherwise, the message becomes "this feature is kind of bad, and at some > > point we might decide to drop it without further notice, but actually we > > might not, so no hurry to remove it", which I just think isn't that > helpful. > > > > I think it would be very helpful. > I would have loved to know that FILTER_SANITIZE_STRING was not > considered a good choice when I recently researched how to improve an > issue. > Deprecation without a fixed removal version is better than no > deprecation (because removal version was not agreed on). > > Actually I agree with everything that Mike said previously and I > strongly suggest a policy that looks like this: > > Deprecation means no longer encouraged (strongly) and might be removed > in a future (major) version. > Before every new major version, review all deprecated features/usages > and decide with a simple RFC if each of them should be removed, > reviewing the current usage level and migration paths. > > Best, > Jakob >
As far as this RFC is concerned (and this is the customary phrasing for all deprecation RFCs), all changes are for deprecation in PHP 8.1 and removal in PHP 9.0. That's the baseline. However, nothing prevents you from starting an RFC prior to the PHP 9.0 release that counters the prior decision and extends the deprecation period for another major version. However, the onus is now on you to argue that something previously deprecated should not be removed (or not be removed yet). If you cannot make a strong argument for that, then the default action is taken. We do still carry a couple deprecations from PHP 5 times around, because actually removing the affected functionality has some technical issues. Regards, Nikita
  115360
July 8, 2021 01:33 mike@newclarity.net (Mike Schinkel)
Replying to Rowan and commenting on Nikita's message.

> On Jul 6, 2021, at 4:24 AM, Rowan Tommins collins@gmail.com> wrote: > >> Instead I replied because your email strongly implied (stated?) that "deprecation required removal" > > I stand by that interpretation, which while not universal is very widely used, and I think is more useful than a general hint at "bad practice". > > You spend most of your e-mail seeming to argue against it, and then seem to say that actually you do agree with it after all, and all you're saying is that sometimes the deprecation period should be longer:
What I was disagreeing with is your assertion that "by definition" deprecation must be followed with near-term removal.
> I am not advocating that. I am advocating we should consider making it: >> >> "features that are strongly discouraged will*probably* be removed in the next major version, but in some cases may be retained for one or more major versions." > > I'm totally OK with that. > > I do think that there should be a clear *plan* for removing each deprecated feature, though. That plan might be "deprecate in 8.1, and examine prior to 9.0 whether usage has dropped / the alternatives are mature / etc". It might flat out be "deprecate in 8.1, but don't remove until 10.0". > > Otherwise, the message becomes "this feature is kind of bad, and at some point we might decide to drop it without further notice, but actually we might not, so no hurry to remove it", which I just think isn't that helpful.
The "plan" that makes the most sense is one that takes into consideration the BC breakage that would occur at the time of removal, and that is not something you can project _in advance_. IMO you cannot really know in advance how long a feature might continue to be used in the wild in some cases, you can only evaluate the current situation when the time comes. Or as they say "no battle plan survives first contact with the enemy" and "facts on the ground matter."
> On Jul 6, 2021, at 9:30 AM, Nikita Popov ppv@gmail.com> wrote: > > As far as this RFC is concerned (and this is the customary phrasing for all > deprecation RFCs), all changes are for deprecation in PHP 8.1 and removal > in PHP 9.0. That's the baseline. > > However, nothing prevents you from starting an RFC prior to the PHP 9.0 > release that counters the prior decision and extends the deprecation period > for another major version. However, the onus is now on you to argue that > something previously deprecated should not be removed (or not be removed > yet). If you cannot make a strong argument for that, then the default > action is taken. > > We do still carry a couple deprecations from PHP 5 times around, because > actually removing the affected functionality has some technical issues.
And this is exactly how it should be. That deprecating a feature w/o near-term removal is a legitimate approach to have people vote on. IOW, that deprecation does not "by definition" require near-term removal. Removal is determined when appropriate and by vote, and not any hard-and-fast "IF deprecated THEN must be removed soon." Please note that I am fully respecting the ballot and voting outcomes here; if people always vote to remove a deprecated feature in next major version that so be it. But RFC authors should be allowed to propose a long time horizon for removal without being told they "are doing it wrong." -Mike
  115371
July 8, 2021 17:26 rowan.collins@gmail.com (Rowan Tommins)
On 08/07/2021 02:33, Mike Schinkel wrote:
> What I was disagreeing with is your assertion that "by definition" > deprecation must be followed with near-term removal.
I think we're talking past each other, and actually mostly agree, but are mixing up two questions: a) Does deprecation always mean planned removal _at some point_? b) *When* does that removal need to happen? My intention all along was to answer question (a) - a deprecation notice should imply that something will *eventually* be removed, not just that it is "bad practice" to use it. That is a common definition, and I think it's one that is useful to users. What we mostly seem to be discussing is question (b), so, for the record, here is what I think: * Removal of a deprecated feature can be at any point in the future, even the indefinite future, just not "never". * Very short deprecation periods can be harmful, because they don't give people enough time to change. * Very long deprecation periods can also be harmful, because people will put off making changes, and end up with a large back log when things are finally removed. * Specific plans are useful to users - "this will be removed in 2024" is easy to base decisions on. * Failing that, any plan is better than no plan at all - it's easier to work with "a decision on this will be made in 2023 based on an estimate of usage at that point" than "at some point between 1 and 100 years from now, we'll remove it without further notice". Regards, -- Rowan Tommins [IMSoP]
  115374
July 9, 2021 00:33 mike@newclarity.net (Mike Schinkel)
> On Jul 8, 2021, at 1:26 PM, Rowan Tommins collins@gmail.com> wrote: > > for the record, here is what I think: > > * Removal of a deprecated feature can be at any point in the future, even the indefinite future, just not "never". > * Very short deprecation periods can be harmful, because they don't give people enough time to change. > * Very long deprecation periods can also be harmful, because people will put off making changes, and end up with a large back log when things are finally removed. > * Specific plans are useful to users - "this will be removed in 2024" is easy to base decisions on. > * Failing that, any plan is better than no plan at all - it's easier to work with "a decision on this will be made in 2023 based on an estimate of usage at that point" than "at some point between 1 and 100 years from now, we'll remove it without further notice".
That is a policy I can concur with. _Definitely_ better than what was stated earlier in the thread. Does anyone else disagree? If no, could this get memorialized on the wiki somewhere to reference in future discussions, if needed? (Or does it need an RFC?) -Mike
  115301
July 5, 2021 12:20 patrickallaert@php.net (Patrick ALLAERT)
Le lun. 5 juil. 2021 à 13:39, Mike Schinkel <mike@newclarity.net> a écrit :

> > On Jul 5, 2021, at 7:14 AM, Rowan Tommins collins@gmail.com> > wrote: > > > > On 05/07/2021 11:46, Patrick ALLAERT wrote: > >> Did we ever deprecated something without the immediate intention of > >> removing it? > > > > > > What would that even mean? > > It would mean that although the functions are available and allowed, they > are not recommended[1]. >
Exactly my point. The fact that it gets deprecated with a notice gets much more visibility than just documentation changes (which I encourage anyway!).
> > Surely a deprecation, by definition, is a notice that something is going > to be removed. > > I know that you, and others on this list, have chosen to define > deprecation as including removal, but that is actually not the accepted > definition on the web, nor is it in any way a requirement, it is just your > preference. > > Indirectly from Wikipedia and voted as the top answer on StackOverflow > here[2] (emphasis MINE): > > "deprecation is a status applied to software features to indicate that > they should be avoided, typically because they have been superseded. > Although deprecated features remain in the software, their use may raise > warning messages recommending alternative practices, and deprecation MAY > indicate that the feature will be removed in the future." > > So I am arguing for the legitimacy of retaining "deprecated" features if > their removal would cause significant BC breakage, I'm not just trying to > be a pendant. >
  115395
July 12, 2021 07:49 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. > The vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. >
The oci8.old_oci_close_semantics deprecation is looking for someone to implement it (I'm not sure who added it in the first place). I have everything else covered, but don't have an oci8 test environment to work on this one. Regards, Nikita
  115402
July 12, 2021 11:37 christopher.jones@oracle.com (Christopher Jones)
On 12/7/21 5:49 pm, Nikita Popov wrote:
> On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov ppv@gmail.com> wrote: > >> Hi internals, >> >> I have opened voting on https://urldefense.com/v3/__https://wiki.php.net/rfc/deprecations_php_8_1__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoU67d5vLg$ . >> The vote closes on 2021-07-14. >> >> This RFC is a collection of various deprecation suggestions from different >> people. Each deprecation is voted separately, and should be considered on >> its own merit. >> >> Most deprecations should be uncontroversial, but there are some more >> contentious ones as well: See https://urldefense.com/v3/__https://externals.io/message/113657__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoXqarWpuA$ for >> additional discussion. >> > The oci8.old_oci_close_semantics deprecation is looking for someone to > implement it (I'm not sure who added it in the first place). I have > everything else covered, but don't have an oci8 test environment to work on > this one. > > Regards, > Nikita > I will do it.
Chris -- https://twitter.com/ghrd
  115424
July 14, 2021 07:30 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov ppv@gmail.com> wrote:

> Hi internals, > > I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. > The vote closes on 2021-07-14. > > This RFC is a collection of various deprecation suggestions from different > people. Each deprecation is voted separately, and should be considered on > its own merit. > > Most deprecations should be uncontroversial, but there are some more > contentious ones as well: See https://externals.io/message/113657 for > additional discussion. >
Here are the results of the vote. The following deprecations have been declined: * get_class(), get_parent_class() and get_called_class() without argument: 21 in favor, 21 against * t fopen mode: 13 in favor, 17 against The following deprecations have been accepted: * date_sunrise() and date_sunset(): 51 in favor, 0 against * key(), current(), next(), prev(), and reset() on objects: 48 in favor, 0 against * mb_check_encoding() without argument: 44 in favor, 0 against * FILE_BINARY and FILE_TEXT constants: 42 in favor, 1 against * Passing bool for $value argument of IntlCalendar::roll(): 38 in favor, 0 against * Accessing static members on traits: 40 in favor, 0 against * strptime(): 35 in favor, 0 against * strftime() and gmtstrftime(): 29 in favor, 9 against * mhash*() function family: 38 in favor, 0 against * ctype_*() function family accepts int parameters: 34 in favor, 2 against * Return by reference with void type: 39 in favor, 1 against * NIL constant defined by the IMAP extension: 35 in favor, 0 against * Calling overloaded pgsql functions without the connection argument: 36 in favor, 1 against * $num_points parameter of image(open|filled)polygon: 20 in favor, 9 against * mysqli::init(): 34 in favor, 0 against * filter.default ini setting: 28 in favor, 4 against * auto_detect_line_endings ini setting: 38 in favor, 0 against * ssl_method option to SoapClient constructor: 25 in favor, 1 against * FILTER_SANITIZE_STRING: 36 in favor, 0 against, * oci8.old_oci_close_semantics ini setting: 27 in favor, 0 against * odbc_result_all(): 34 in favor, 0 against Regards, Nikita