On 2-7-2024 20:05, Gina P. Banyard wrote:
On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer
<php-internals_nos...@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
