Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123818
Precedence: bulk
MIME-Version: 1.0
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
In-Reply-To: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
Date: Tue, 25 Jun 2024 17:27:20 +0200
Message-ID: <CADyq6sLuz3430TRMu8cSh5_x57UBaWA8v4sr_c+OgUSjn-otBQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: PHP internals <internals@lists.php.net>, timwolla@php.net
Content-Type: multipart/alternative; boundary="0000000000005fafaf061bb88912"
From: ocramius@gmail.com (Marco Pivetta)

--0000000000005fafaf061bb88912
Content-Type: text/plain; charset="UTF-8"

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
>

--0000000000005fafaf061bb88912
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hey Gina, Tim,</div><div><br></div><div>I agree with =
most of these deprecations, except:</div><div><br></div><div>=C2=A0* `uniqi=
d()`, 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 qui=
te messy code, or added dependencies. IMO fine to get rid of **this specifi=
c implementation**, if a safe function is provided, such as `random_ascii_s=
tring()` or such (dunno, just a hint)<br></div><div>=C2=A0* `md5()`, `sha1(=
)` - OK-ish with moving to `hash(&#39;&lt;algo&gt;&#39;, ...)`, but while t=
hese are insecure for most use-cases, they are part of the domain of many t=
ools, including GIT itself. I can Rector my way out of it, just not sure th=
ese should be hidden into `hash(...)`</div><div><br></div><div>That said, w=
elcome changes :-) <br></div><div><br></div><div><div><div dir=3D"ltr" clas=
s=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">M=
arco Pivetta <br><br><a href=3D"https://mastodon.social/@ocramius" target=
=3D"_blank">https://mastodon.social/@ocramius</a><br><br><a href=3D"https:/=
/ocramius.github.io/" target=3D"_blank">https://ocramius.github.io/</a><br>=
</div></div></div><br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, 25 Jun 2024 at 16:37, Gina P. Banyard=
 &lt;internals@gpb.moe&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">Hello internals,<br>
<br>
It is this time of year again where we proposed a list of deprecations to a=
dd in PHP 8.4:<br>
<br>
<a href=3D"https://wiki.php.net/rfc/deprecations_php_8_4" rel=3D"noreferrer=
" target=3D"_blank">https://wiki.php.net/rfc/deprecations_php_8_4</a><br>
<br>
As a reminder, this list has been compiled over the course of the past year=
 by various different people.<br>
<br>
And as usual, each deprecation will be voted in isolation.<br>
<br>
We still have a bit of time buffer, so if anyone else has any suggestions, =
they are free to add them to the RFC.<br>
<br>
Some should be non-controversial, others a bit more.<br>
If such, they might warrant their own dedicated RFC, or be dropped from the=
 proposal altogether.<br>
<br>
<br>
Best regards,<br>
<br>
Gina P. Banyard<br>
</blockquote></div>

--0000000000005fafaf061bb88912--