Re: [RFC] Deprecations for PHP 8.4

From: 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 >

« previous php.internals (#123818) next »