[VOTE] Deprecations for PHP 8.1

4 years ago by Dan Ackroyd — view source — reply

unread

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

4 years ago by Pierre Joye — view source — reply

unread

Hi Nikita,

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.

4 years ago by Christoph M. Becker — view source — reply

unread

Hi Nikita,

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

4 years ago by Pierre Joye — view source — reply

unread

Hi Nikita,

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

4 years ago by Dmitry Stogov — view source — reply

unread

Return void by reference should be disabled (not deprecated)

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

4 years ago by Patrick ALLAERT — view source — reply

unread

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.

4 years ago by Marco Pivetta — view source — reply

unread

Hey Nikita,

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/

4 years ago by Patrick ALLAERT — view source — reply

unread

Le mer. 30 juin 2021 à 11:32, Nikita Popov nikita.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?

4 years ago by Rowan Tommins — view source — reply

unread

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]

4 years ago by Mike Schinkel — view source — reply

unread

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

4 years ago by Guilliam Xavier — view source — reply

unread

On Jul 5, 2021, at 7:14 AM, Rowan Tommins rowan.collins@gmail.com
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

4 years ago by G. P. B. — view source — reply

unread

On Jul 5, 2021, at 7:14 AM, Rowan Tommins rowan.collins@gmail.com
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

4 years ago by Rowan Tommins — view source — reply

unread

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]

4 years ago by Mike Schinkel — view source — reply

unread

Replying in one long email to all three who replied to me:

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*.

In general (no pun intended), is it a good idea for PHP to take a general concept and redefine its meaning? (Rhetorical question.)
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.
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.

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.

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.")

Wiktionary: https://en.wiktionary.org/wiki/deprecated

"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.)

The Drupal Core deprecation policy: https://www.drupal.org/about/core/policies/core-change-policies/drupal-core-deprecation-policy

"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?)

4 years ago by Rowan Tommins — view source — reply

unread

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 willprobably 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]

4 years ago by Jakob Givoni — view source — reply

unread

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 willprobably 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

4 years ago by Nikita Popov — view source — reply

unread

On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins rowan.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 willprobably 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

4 years ago by Mike Schinkel — view source — reply

unread

Replying to Rowan and commenting on Nikita's message.

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 willprobably 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."

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

4 years ago by Rowan Tommins — view source — reply

unread

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]

4 years ago by Mike Schinkel — view source — reply

unread

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

4 years ago by Patrick ALLAERT — view source — reply

unread

Le lun. 5 juil. 2021 à 13:39, Mike Schinkel mike@newclarity.net a écrit :

On Jul 5, 2021, at 7:14 AM, Rowan Tommins rowan.collins@gmail.com
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.

4 years ago by Nikita Popov — view source — reply

unread

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

4 years ago by Christopher Jones — view source — reply

unread

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

4 years ago by Nikita Popov — view source — reply

unread

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