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
