Re: [RFC] Deprecations for PHP 8.4
| From: | Marco Pivetta | Date: | Tue, 25 Jun 2024 15:27:20 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 8.4 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-123818@lists.php.net to get a copy of this message | ||
Hey Gina, Tim,
I agree with most of these deprecations, except:
*
uniqid(), in my case (XKCD 1172) is largely used for quickly
generating a semi-random string for test purposes: a suitable replacement
PRNG implementation would be welcome. Even refactoring with tools like
Rector will lead to quite messy code, or added dependencies. IMO fine to
get rid of **this specific implementation**, if a safe function is
provided, such as random_ascii_string() or such (dunno, just a hint)
* md5(), sha1() - OK-ish with moving to
hash('<algo>', ...), but
while these are insecure for most use-cases, they are part of the domain of
many tools, including GIT itself. I can Rector my way out of it, just not
sure these should be hidden into hash(...)
That said, welcome changes :-)
Marco Pivetta
https://mastodon.social/@ocramius
https://ocramius.github.io/
On Tue, 25 Jun 2024 at 16:37, Gina P. Banyard <internals@gpb.moe> 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
>