Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124272
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: internals@lists.php.net
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
 <6683CDE4.7050607@adviesenzo.nl>
 <Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe>
Message-ID: <668B5728.40300@adviesenzo.nl>
Date: Mon, 8 Jul 2024 05:04:08 +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: <Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe>
Content-Type: multipart/alternative;
 boundary="------------040400070102030007060103"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------040400070102030007060103
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2-7-2024 20:05, Gina P. Banyard wrote:
> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer 
> <php-internals_nospam@adviesenzo.nl> wrote:
>> 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
>>>
>>

Thanks for making those updates Gina!

>>
>> * 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.
>
> You will need to clarify which ones you are talking about.
> These "bulk removal" RFCs are written by various authors over the 
> course of a year, and might not have been looked at for 9+ months.

I'd suggest for an impact analysis/expected impact statement to be added 
to the following deprecation proposals:
* session.sid_length and session.sid_bits_per_character
* xml_set_object() and xml_set_*_handler() with string method names
* Deprecate proprietary CSV escaping mechanism
* Deprecate strtok() function
* Deprecate returning non-strings values from a user output handler
* Deprecate producing output in a user output handler
* Deprecate mysqli_refresh()
* Deprecate mysqli_kill()
* Deprecate lcg_value()
* Deprecate md5(), sha1(), md5_file(), and sha1_file() (add an actual 
analysis, not just a statement as this is a high impact proposal)
* Deprecate passing E_USER_ERROR to trigger_error()
* Deprecate SOAP_FUNCTIONS_ALL constant and passing it to 
SoapServer::addFunction()

And to a lesser degree for:
* Formally deprecate Soft-deprecated DOMDocument and DOMEntity properties
* Deprecate SplFixedArray::__wakeup()
* Deprecate passing null and false to dba_key_split()
* Deprecate passing incorrect data types for options to ext/hash functions
* Constants SUNFUNCS_RET_STRING, SUNFUNCS_RET_DOUBLE, SUNFUNCS_RET_TIMESTAMP
* Remove E_STRICT error level and deprecate E_STRICT constant
* mysqli_ping() and mysqli::ping()


P.S.: typo in "xml_set_object() and xml_set_*_handler() with string 
method names": "witch" => "which"

>> 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.
>
> If I may be a bit cheeky, if we consider that userland does not 
> understand that deprecations are not errors, how can we trust them to 
> use the 5 aforementioned functions correctly?
> Especially as there are more appropriate replacements available.

There is a difference between "userland"  (dev-users) and end-users. I 
was talking about end-users, while based on your remark, you are talking 
about dev-users.

I also don't agree that there are "more appropriate replacements available".
The  suggested `hash()` replacements for the md5/sha1* functions have 
the exact same functionality, which the RFC considers "incorrect use", 
so what are we actually solving by this deprecation ? Devs not having 
enough to do already ?
The problem (for open source) with "force-replacing" the uses of 
`md5/sha1*` functions with the `hash` function calls, is that the hash 
extension was not part of PHP core until PHP 7.4, which means that for a 
significant number of open source projects, the replacement is not a 
one-on-one function call replacement, but needs guard code for PHP < 7.4 
in case the hash extension is not available.


Also, having read through the RFC a second time, I find the voting 
choices inconsistent - in particular the first deprecation vote, which 
makes the others ambiguous.
Could each voting choice please be explicitly one of the below to 
prevent any confusion ?
* Remove in PHP 8.4
* Deprecate in PHP 8.4 and remove in PHP 9
* Deprecate in PHP 8.4 and remove at a later date after a separate vote


Smile,
Juliette

--------------040400070102030007060103
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 2-7-2024 20:05, Gina P. Banyard
      wrote:<br>
    </div>
    <blockquote
cite="mid:Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe"
      type="cite">
      <div class="protonmail_quote">On Tuesday, 2 July 2024 at 10:52,
        Juliette Reinders Folmer
        <a class="moz-txt-link-rfc2396E" href="mailto:php-internals_nospam@adviesenzo.nl">&lt;php-internals_nospam@adviesenzo.nl&gt;</a> wrote:<br>
        <blockquote class="protonmail_quote" type="cite">
          <div class="moz-cite-prefix">On 25-6-2024 16:36, Gina P.
            Banyard wrote:<br>
          </div>
          <blockquote 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 moz-do-not-send="true" href="https://wiki.php.net/rfc/deprecations_php_8_4" class="moz-txt-link-freetext" rel="noreferrer nofollow noopener" target="_blank">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>
        </blockquote>
      </div>
    </blockquote>
    <br>
    Thanks for making those updates Gina!<br>
    <br>
    <blockquote
cite="mid:Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe"
      type="cite">
      <div class="protonmail_quote">
        <blockquote class="protonmail_quote" type="cite"><br>
          * While a number of proposals include an impact analysis
          (thank you!), a significant number of the proposals don't.<br>
          <div> It would be appreciated if for those proposals which
            aren't removing unused/unusable functionality, some sort of
            impact analysis was added.<br>
          </div>
        </blockquote>
        <div style="font-family: Arial, sans-serif; font-size: 14px;
          color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br>
        </div>
        <div style="font-family: Arial, sans-serif; font-size: 14px;
          color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">You

          will need to clarify which ones you are talking about.</div>
        <div style="font-family: Arial, sans-serif; font-size: 14px;
          color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">These

          "bulk removal" RFCs are written by various authors over the
          course of a year, and might not have been looked at for 9+
          months.</div>
      </div>
    </blockquote>
    <br>
    I'd suggest for an impact analysis/expected impact statement to be
    added to the following deprecation proposals:<br>
    * session.sid_length and session.sid_bits_per_character<br>
    * xml_set_object() and xml_set_*_handler() with string method names<br>
    * Deprecate proprietary CSV escaping mechanism<br>
    * Deprecate strtok() function<br>
    * Deprecate returning non-strings values from a user output handler<br>
    * Deprecate producing output in a user output handler<br>
    * Deprecate mysqli_refresh()<br>
    * Deprecate mysqli_kill()<br>
    * Deprecate lcg_value()<br>
    * Deprecate md5(), sha1(), md5_file(), and sha1_file() (add an
    actual analysis, not just a statement as this is a high impact
    proposal)<br>
    * Deprecate passing E_USER_ERROR to trigger_error()<br>
    * Deprecate SOAP_FUNCTIONS_ALL constant and passing it to
    SoapServer::addFunction()<br>
    <br>
    And to a lesser degree for:<br>
    * Formally deprecate Soft-deprecated DOMDocument and DOMEntity
    properties<br>
    * Deprecate SplFixedArray::__wakeup()<br>
    * Deprecate passing null and false to dba_key_split()<br>
    * Deprecate passing incorrect data types for options to ext/hash
    functions<br>
    * Constants SUNFUNCS_RET_STRING, SUNFUNCS_RET_DOUBLE,
    SUNFUNCS_RET_TIMESTAMP<br>
    * Remove E_STRICT error level and deprecate E_STRICT constant<br>
    * mysqli_ping() and mysqli::ping()<br>
    <br>
    <br>
    P.S.: typo in "xml_set_object() and xml_set_*_handler() with string
    method names": "witch" =&gt; "which"<br>
    <br>
    <blockquote
cite="mid:Skh-IB3l7OxslclNZdB5ZE3G5PaIvpoz3iojK10noNbXkj1odNNvzI5w7X1aSj7IKZ951646yQ8IrUW_wNaQuv94NB0jo3IXlFImcpu_hxc=@gpb.moe"
      type="cite">
      <div class="protonmail_quote">
        <blockquote class="protonmail_quote" type="cite"> 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>
          <div> 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.</div>
        </blockquote>
        <div style="font-family: Arial, sans-serif; font-size: 14px;
          color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br>
        </div>
        <div style="font-family: Arial, sans-serif; font-size: 14px;
          color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">If
          I may be a bit cheeky, if we consider that userland does not
          understand that deprecations are not errors, how can we trust
          them to use the 5 aforementioned functions correctly?</div>
        <div style="font-family: Arial, sans-serif; font-size: 14px;
          color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">Especially

          as there are more appropriate replacements available.<br>
        </div>
      </div>
    </blockquote>
    <br>
    There is a difference between "userland"  (dev-users) and end-users.
    I was talking about end-users, while based on your remark, you are
    talking about dev-users.<br>
    <br>
    I also don't agree that there are "more appropriate replacements
    available".<br>
    The  suggested `hash()` replacements for the md5/sha1* functions
    have the exact same functionality, which the RFC considers
    "incorrect use", so what are we actually solving by this deprecation
    ? Devs not having enough to do already ?<br>
    The problem (for open source) with "force-replacing" the uses of
    `md5/sha1*` functions with the `hash` function calls, is that the
    hash extension was not part of PHP core until PHP 7.4, which means
    that for a significant number of open source projects, the
    replacement is not a one-on-one function call replacement, but needs
    guard code for PHP &lt; 7.4 in case the hash extension is not
    available.<br>
    <br>
    <br>
    Also, having read through the RFC a second time, I find the voting
    choices inconsistent - in particular the first deprecation vote,
    which makes the others ambiguous.<br>
    Could each voting choice please be explicitly one of the below to
    prevent any confusion ?<br>
    * Remove in PHP 8.4<br>
    * Deprecate in PHP 8.4 and remove in PHP 9<br>
    * Deprecate in PHP 8.4 and remove at a later date after a separate
    vote<br>
    <br>
    <br>
    Smile,<br>
    Juliette
  </body>
</html>

--------------040400070102030007060103--