Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123882
Precedence: bulk
MIME-Version: 1.0
References: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
In-Reply-To: <bw20I5b7ly3lSbI-2Bv3kfrfTVJbDo5RhwBiQa1PEwuLjprDJWptPajLiaialj1RLVKu7z1j0MofJUhhRVtzT_5i2E11oKeQx_VMUxnKhUE=@gpb.moe>
Date: Wed, 26 Jun 2024 15:19:27 -0400
Message-ID: <CALGLHq1oQs6J3FLKPegVrgDbxt0qCVGxpSb2_JTvf0c_wH3taw@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>
Content-Type: multipart/alternative; boundary="00000000000039e754061bcfe57a"
From: morganbreden@gmail.com (Morgan)

--00000000000039e754061bcfe57a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I do not believe it is appropriate to deprecate strtok() without a proper
replacement.

While I agree that its signature is undesirable, the suggested replacement
functions or =E2=80=9Cjust write a parser=E2=80=9D are not very pleasant so=
lutions to fill
the void it would leave.

The stateful functionality it exhibits is incredibly useful, though I will
admit confusing. Would it not be better to change how the functionality is
accessed to reflect the fact that state is preserved rather than remove it
entirely and force a performance burden on developers?

On Tue, Jun 25, 2024 at 10:38=E2=80=AFAM 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
>

--00000000000039e754061bcfe57a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I do not believe it is appropriate to deprecate strtok() =
without a proper replacement.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">While I agree that its signature is undesirable, the suggested replac=
ement functions or =E2=80=9Cjust write a parser=E2=80=9D are not very pleas=
ant solutions to fill the void it would leave.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">The stateful functionality it exhibits is incredibly=
 useful, though I will admit confusing. Would it not be better to change ho=
w the functionality is accessed to reflect the fact that state is preserved=
 rather than remove it entirely and force a performance burden on developer=
s?=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">On Tue, Jun 25,=
 2024 at 10:38=E2=80=AFAM Gina P. Banyard &lt;internals@gpb.moe&gt; wrote:<=
br></div><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;padding-left:1ex;border-left-color:rgb(204,204,204)">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></div>

--00000000000039e754061bcfe57a--