Re: [RFC] Deprecations for PHP 8.4
| From: | Juliette Reinders Folmer | Date: | Mon, 08 Jul 2024 05:05:58 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 8.4 | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-124277@lists.php.net to get a copy of this message | ||
On 8-7-2024 6:57, Andreas Heigl wrote:
Am 08.07.24 um 05:04 schrieb Juliette Reinders Folmer: [...]Agreed, but the fact that it is solvable, is not a justification for adding "busy-work" when the replacement for the deprecated function is, by all accounts, just as bad/incorrect as the original.... I don't mind putting the work in when there is a good justification, but I don't see one for this deprecation. Smile, JulietteI also don't agree that there are "more appropriate replacements available". The suggestedFrom the docs it looks like the hash function was part of the core since php 5.1.2 but perhaps I read that wrongly from the docs. Anyhow, a replacement could possibly be to declare a userland function that then does the version check and either calls the respective function directly or delegates to the hash-function.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 ofmd5/sha1*functions with thehashfunction 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.