On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer
<[email protected]> 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
>
> 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.
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.
> * 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.
Those properties have been soft deprecated for a long time, the proposal is to formally deprecate
them.
I've clarified this.
> * 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.
The migration path is available since at least PHP 5.3, probably even longer.
Instead of calling xml_set_object() with an object $obj, and e.g. xml_set_default_handler() with a
string corresponding to the name of a method of $obj,
you should set the handler with a proper callable, i.e. using [$obj, 'methodOfObj'] as the
handler.
> * CSV escaping section: please make it explicit which functions will be affected by this
> proposal.
Done.
> * 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) ) ?)
Done.
> 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.
> 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.
In that case, calling exit() with a string will provide you more consistent behaviour, and also run
destructors and finally blocks.
The main motivation to remove it is to curtail the usage of the bailout mechanism, as it has various
issues explained in the linked RFC.
I have added this to the section.
> 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().
I forgot about error_reporting, I moved it out of the RFC and for something to be tackled at a later
date.
Best regards,
Gina P. Banyard