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 <intern...@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
>

Reply via email to