Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124174
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: internals@lists.php.net
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
Message-ID: <6683CDE4.7050607@adviesenzo.nl>
Date: Tue, 2 Jul 2024 11:52:36 +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: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
Content-Type: multipart/alternative;
 boundary="------------000504050504090407000403"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------000504050504090407000403
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 25-6-2024 16:36, 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.4:
>
> https://wiki.php.net/rfc/deprecations_php_8_4
>
> 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
>

I've read through the complete set of proposals and have the following 
observations:

* While a number of proposals include an impact analysis (thank you!), a 
significant number of the proposals don't.
     It would be appreciated if for those proposals which aren't 
removing unused/unusable functionality, some sort of impact analysis was 
added.

* DomDocument and DomEntity properties section: the text seems to 
contradict itself - the proposal seems to suggest to soft-deprecate 
something which is already soft deprecated. Some clarification of what 
the actual proposal is, would be helpful.

* `xml_set_object()` section: the mitigation path for this deprecation 
is unclear and more so, it is unclear as of which PHP version the 
mitigation path is available (if there are restrictions). It would be 
helpful if some example code was added to show the mitigation path more 
clearly.

* CSV escaping section: please make it explicit which functions will be 
affected by this proposal.

* `file_put_contents()` section: please make the mitigation path 
explicit (which I presume would be something along the lines of 
`file_put_contents( $filename, implode('', $data) )` ?)


Other than that, I join the previously voiced objections to the 
deprecation of `uniqid()`, `md5()`, `sha1()`, `md5_file()`, `sha1_file()`.
While I acknowledge that these functions _can_ be used inappropriately 
for security-sensitive code, which should use alternative methods, these 
functions have perfectly valid use-cases for non-security-sensitive code 
and the impact of the BC-break of deprecating and eventually removing 
these methods can, IMO, not be justified.
Keep in mind that while "we" know and understand that deprecations are 
not errors, end-users often don't and particularly for open source 
projects, this means that in practice these deprecations will need to be 
addressed anyway to reduce the noise of users opening issues about them, 
which without a clear path to removal of the functions, will, in a lot 
of cases, mean adding the `@` operator to all uses.

Regarding the deprecation of using `E_USER_ERROR` in `trigger_error()`: 
there are errors which should never be caught and using 
`trigger_error()` with `E_USER_ERROR` is appropriate for those.
The fact that execution can be returned to the code via 
`set_error_handler()` returning `true` sounds to me like a bug which 
should be fixed, rather than disabling the functionality for userland 
code to hard exit with an error when deemed appropriate.

As for deprecating the `E_USER_ERROR` constant, this will lead to a lot 
of guard code needing to be added for calls to `error_reporting()` as 
well as in custom error handler functions, when the (open source) code 
needs to be PHP cross version compatible.
In my opinion, this deprecation proposal should be moved to a later 
major than a deprecation of using `E_USER_ERROR` in `trigger_error()`.

Either way, these are two pennies.

Smile,
Juliette




--------------000504050504090407000403
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<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 25-6-2024 16:36, Gina P. Banyard
      wrote:<br>
    </div>
    <blockquote
cite="mid:bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@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.4:

<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/deprecations_php_8_4">https://wiki.php.net/rfc/deprecations_php_8_4</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>
    I've read through the complete set of proposals and have the
    following observations:<br>
    <br>
    * While a number of proposals include an impact analysis (thank
    you!), a significant number of the proposals don't.<br>
        It would be appreciated if for those proposals which aren't
    removing unused/unusable functionality, some sort of impact analysis
    was added.<br>
    <br>
    * DomDocument and DomEntity properties section: the text seems to
    contradict itself - the proposal seems to suggest to soft-deprecate
    something which is already soft deprecated. Some clarification of
    what the actual proposal is, would be helpful.<br>
    <br>
    * `xml_set_object()` section: the mitigation path for this
    deprecation is unclear and more so, it is unclear as of which PHP
    version the mitigation path is available (if there are
    restrictions). It would be helpful if some example code was added to
    show the mitigation path more clearly.<br>
    <br>
    * CSV escaping section: please make it explicit which functions will
    be affected by this proposal.<br>
    <br>
    * `file_put_contents()` section: please make the mitigation path
    explicit (which I presume would be something along the lines of
    `file_put_contents( $filename, implode('', $data) )` ?)<br>
    <br>
    <br>
    Other than that, I join the previously voiced objections to the
    deprecation of `uniqid()`, `md5()`, `sha1()`, `md5_file()`,
    `sha1_file()`.<br>
    While I acknowledge that these functions _can_ be used
    inappropriately for security-sensitive code, which should use
    alternative methods, these functions have perfectly valid use-cases
    for non-security-sensitive code and the impact of the BC-break of
    deprecating and eventually removing these methods can, IMO, not be
    justified.<br>
    Keep in mind that while "we" know and understand that deprecations
    are not errors, end-users often don't and particularly for open
    source projects, this means that in practice these deprecations will
    need to be addressed anyway to reduce the noise of users opening
    issues about them, which without a clear path to removal of the
    functions, will, in a lot of cases, mean adding the `@` operator to
    all uses.<br>
    <br>
    Regarding the deprecation of using `E_USER_ERROR` in
    `trigger_error()`: there are errors which should never be caught and
    using `trigger_error()` with `E_USER_ERROR` is appropriate for
    those.<br>
    The fact that execution can be returned to the code via
    `set_error_handler()` returning `true` sounds to me like a bug which
    should be fixed, rather than disabling the functionality for
    userland code to hard exit with an error when deemed appropriate.<br>
    <br>
    As for deprecating the `E_USER_ERROR` constant, this will lead to a
    lot of guard code needing to be added for calls to
    `error_reporting()` as well as in custom error handler functions,
    when the (open source) code needs to be PHP cross version
    compatible.<br>
    In my opinion, this deprecation proposal should be moved to a later
    major than a deprecation of using `E_USER_ERROR` in
    `trigger_error()`.<br>
    <br>
    Either way, these are two pennies.<br>
    <br>
    Smile,<br>
    Juliette<br>
    <br>
    <br>
    <br>
  </body>
</html>

--------------000504050504090407000403--