Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128222
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: internals@lists.php.net
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Message-ID: <68830C4F.5020107@adviesenzo.nl>
Date: Fri, 25 Jul 2025 06:47:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
Content-Type: multipart/alternative;
 boundary="------------010300080509060900090203"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------010300080509060900090203
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2-7-2025 21:56, Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past year by various different people.
>
> And as usual, each deprecation will be voted in isolation.
>
> We still have a bit of time buffer, so if anyone else has any suggestions, they are free to add them to the RFC.
>
> Some should be non-controversial, others a bit more.
> If such, they might warrant their own dedicated RFC, or be dropped from the proposal altogether.
>
> Best regards,
>
> Gina P. Banyard
>

Just leaving a note here that I find it inconceivable that the fast 
majority of proposed deprecation (again) do NOT have an impact analysis.

I've spoken up about this before and will continue to do this as it 
basically means a "blind vote", where voters can only rely on their own 
experience to gauge the impact and I expect the majority of voters to 
predominantly work on code which already follows a lot of best 
practices, which skews the vote towards deprecation, disregarding the 
real world impact on less clean codebases.

As for the proposed deprecations themselves (aside from the fact that 
the sheer number of proposed deprecations is quite staggering, but 
that's been mentioned before), I'm just leaving some opinion here for 
voters to chew on:

== Deprecate semicolon after case in switch statement ==

Opinion: Feels like an unnecessary deprecation.

Side-note: The deprecation is also already flagged by PHPCS and will be 
auto-fixable as of PHP_CodeSniffer 3.13.3 (via the 
PSR2.ControlStructures.SwitchDeclaration sniff).

== Deprecate attributes applying to multiple class properties/constants ==

Opinion: while multi-constant and multi-property declarations are not 
all that common (as PSR-2 forbids them), they are supported in PHP, so I 
don't see why it would be necessary to make them second-class citizens 
with this deprecation.

Next you won't be able to type multi-constant and multi-property 
declarations.... this feels like a wrong turn.

== Deprecate backticks as an alias for shell_exec ==

Opinion: Feels like an unnecessary deprecation unless another purpose 
for the backtick operator is already planned, in which case, please 
mention it.

== Deprecate the __sleep() and __wakeup() magic methods ==

Opinion: I foresee this deprecation being problematic for code which 
needs to support a wider range of PHP versions than just the latest and 
greatest. These are often used to block (un)serialization for security 
reasons.

== Deprecate using values null as an array offset and when calling 
array_key_exists() ==

Opinion: I fear this will just lead to people blindly adding type casts 
instead of the code being properly fixed.

== Deprecate Reflection*::setAccessible() ==

Opinion: will probably cause quite a lot of busy-work/code churn, but I 
also see the point of adding the deprecation notice.

== Deprecate ReflectionProperty::getDefaultValue() for properties 
without default values ==

Opinion: I expect this will cause busy-work again, for little real world 
gain.

== Deprecate passing spl_autoload_call() to spl_autoload_unregister() ==

Opinion: I'm willing to bet there is at least one codebase doing this 
deliberately to remove all autoloading callbacks. Having said, the 
alternative seems reasonable enough.

== Deprecate non-canonical type names for settype() ==

I seem to remember seeing mention of this deprecation proposal being 
withdrawn, but it's still in the RFC ?

Opinion: I foresee problems with this deprecation as the `gettype()` 
method returns the long values, so it would break any code which uses 
some combination of `settype()` and `gettype()`.

== Deprecate FILTER_DEFAULT constant ==

Opinion: I expect this may have a higher impact than anticipated. I also 
wonder if the deprecation notice shouldn't mention/suggest using a 
proper filter instead ?

== Make $filter parameter mandatory for filter_*() functions ==

Opinion: makes sense, but I expect this will yield quite some busy work 
again.

== Deprecate no-op functions from the resource to object conversion ==

Opinion: makes sense as a follow-up, but will cause yet more busy work 
to add the `@` operator everywhere these functions are used in PHP code 
supporting a wide range of PHP versions.

---

The other deprecations either make sense to me or I have no opinion on them.

Smile,
Juliette








--------------010300080509060900090203
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 2-7-2025 21:56, Gina P. Banyard
      wrote:<br>
    </div>
    <blockquote
cite="mid:hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe"
      type="cite">
      <pre wrap="">Hello internals,

It is this time of year again where we proposed a list of deprecations to add in PHP 8.5:

<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/deprecations_php_8_5">https://wiki.php.net/rfc/deprecations_php_8_5</a>

As a reminder, this list has been compiled over the course of the past year by various different people.

And as usual, each deprecation will be voted in isolation.

We still have a bit of time buffer, so if anyone else has any suggestions, they are free to add them to the RFC.

Some should be non-controversial, others a bit more.
If such, they might warrant their own dedicated RFC, or be dropped from the proposal altogether.

Best regards,

Gina P. Banyard

</pre>
    </blockquote>
    <br>
    Just leaving a note here that I find it inconceivable that the fast
    majority of proposed deprecation (again) do NOT have an impact
    analysis.<br>
    <br>
    I've spoken up about this before and will continue to do this as it
    basically means a "blind vote", where voters can only rely on their
    own experience to gauge the impact and I expect the majority of
    voters to predominantly work on code which already follows a lot of
    best practices, which skews the vote towards deprecation,
    disregarding the real world impact on less clean codebases.<br>
    <br>
    As for the proposed deprecations themselves (aside from the fact
    that the sheer number of proposed deprecations is quite staggering,
    but that's been mentioned before), I'm just leaving some opinion
    here for voters to chew on:<br>
    <br>
    == Deprecate semicolon after case in switch statement ==<br>
    <br>
    Opinion: Feels like an unnecessary deprecation.<br>
    <br>
    Side-note: The deprecation is also already flagged by PHPCS and will
    be auto-fixable as of PHP_CodeSniffer 3.13.3 (via the
    PSR2.ControlStructures.SwitchDeclaration sniff).<br>
    <br>
    == Deprecate attributes applying to multiple class
    properties/constants ==<br>
    <br>
    Opinion: while multi-constant and multi-property declarations are
    not all that common (as PSR-2 forbids them), they are supported in
    PHP, so I don't see why it would be necessary to make them
    second-class citizens with this deprecation.<br>
    <br>
    Next you won't be able to type multi-constant and multi-property
    declarations.... this feels like a wrong turn.<br>
    <br>
    == Deprecate backticks as an alias for shell_exec ==<br>
    <br>
    Opinion: Feels like an unnecessary deprecation unless another
    purpose for the backtick operator is already planned, in which case,
    please mention it.<br>
    <br>
    == Deprecate the __sleep() and __wakeup() magic methods ==<br>
    <br>
    Opinion: I foresee this deprecation being problematic for code which
    needs to support a wider range of PHP versions than just the latest
    and greatest. These are often used to block (un)serialization for
    security reasons.<br>
    <br>
    == Deprecate using values null as an array offset and when calling
    array_key_exists() ==<br>
    <br>
    Opinion: I fear this will just lead to people blindly adding type
    casts instead of the code being properly fixed.<br>
    <br>
    == Deprecate Reflection*::setAccessible() ==<br>
    <br>
    Opinion: will probably cause quite a lot of busy-work/code churn,
    but I also see the point of adding the deprecation notice.<br>
    <br>
    == Deprecate ReflectionProperty::getDefaultValue() for properties
    without default values ==<br>
    <br>
    Opinion: I expect this will cause busy-work again, for little real
    world gain.<br>
    <br>
    == Deprecate passing spl_autoload_call() to
    spl_autoload_unregister() ==<br>
    <br>
    Opinion: I'm willing to bet there is at least one codebase doing
    this deliberately to remove all autoloading callbacks. Having said,
    the alternative seems reasonable enough.<br>
    <br>
    == Deprecate non-canonical type names for settype() ==<br>
    <br>
    I seem to remember seeing mention of this deprecation proposal being
    withdrawn, but it's still in the RFC ?<br>
    <br>
    Opinion: I foresee problems with this deprecation as the `gettype()`
    method returns the long values, so it would break any code which
    uses some combination of `settype()` and `gettype()`.<br>
    <br>
    == Deprecate FILTER_DEFAULT constant ==<br>
    <br>
    Opinion: I expect this may have a higher impact than anticipated. I
    also wonder if the deprecation notice shouldn't mention/suggest
    using a proper filter instead ?<br>
    <br>
    == Make $filter parameter mandatory for filter_*() functions ==<br>
    <br>
    Opinion: makes sense, but I expect this will yield quite some busy
    work again.<br>
    <br>
    == Deprecate no-op functions from the resource to object conversion
    ==<br>
    <br>
    Opinion: makes sense as a follow-up, but will cause yet more busy
    work to add the `@` operator everywhere these functions are used in
    PHP code supporting a wide range of PHP versions.<br>
    <br>
    ---<br>
    <br>
    The other deprecations either make sense to me or I have no opinion
    on them.<br>
    <br>
    Smile,<br>
    Juliette<br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------010300080509060900090203--