Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.6

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

Hi,

On Tue, Jul 28, 2026 at 3:50=E2=80=AFPM Pierre Joye <[email protected]> =
wrote:

> Hey Jakub,
>
> On Tue, Jul 28, 2026 at 5:16=E2=80=AFPM Jakub Zelenka <[email protected]> wro=
te:
>
> >
> > This is exactly a half baked deprecation because we need to keep it for
> internal use anyway (it uses http stream wrapper for chunked encoding) so
> this does not give us any code removal and we still need to maintain it. =
I
> don=E2=80=99t understand why we need to rush it as there is no real reaso=
n for that.
>
> Yes and no. Having internal uses only down the road is significantly
> easier to deal with than having to support this from a userland
> perspective. There is some time to think about it and make it cleaner
> or safer to be used for the purpose of fopen/file_get_contents like
> usages. But the select issues may remain, not sure yet. I don't think
> this is something that can't be solved.
>

I actually resolved that select issue (if it's what I think it is -
limitation using select on filtered streams which I got rid of) in the
current master so it will be part of 8.6. See
https://github.com/php/php-src/pull/20540 .


>
> > Also we cannot just decide not to deprecate it in RC. We would need
> extra approval from RM and then new RFC. We had exactly this sort of
> situation last year with __sleep and it was huge pain to change. It also
> took lots of our time that we could use for much more important stuff.
>
> I hear you.
>
> Important has very different lists depending who we talk to. And
> everyone has time when it is possible, being paid to do it or in their
> free time. Cumulated time to deal with something we know is broken and
> we could fix in a decade or more surely used an order of magnitude
> time for too many people than reveriting a deprecation or adapting it.
> Even if it happens some RMs will need to deal with it, but you and
> others are not alone, dropping a mail here does not hurt and I am sure
> some, or I when I know the area, can jump in too. Communication is
> sometimes hard but amazingly helpful :).
>
>
The problem is that there wasn't enough time to properly investigate if the
things can be improved on the C side. There was just some bug and then
immediate proposal to deprecate it without first not even realising that
it's used by chunked encdoing which I needed to point out. Then the idea
was to deprecate it for user space only which I actually wasn't against as
I assumed there was a proper research into the the usage but that wasn't
the case because Nicolas then pointed out that it is used in Symfony but
the deprecation proposal didn't get removed.

What I think is that deprecation should be proposed only if there a deep
knowledge of the problem and the context which I'm not sure is the case
here (and in some other proposals as well).

Kind regards,

Jakub

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

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 28, 2026 at 3:50=
=E2=80=AFPM Pierre Joye &lt;<a href=3D"mailto:[email protected]">pierre.=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">Hey Jakub,<br>
<br>
On Tue, Jul 28, 2026 at 5:16=E2=80=AFPM Jakub Zelenka &lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt; This is exactly a half baked deprecation because we need to keep it fo=
r internal use anyway (it uses http stream wrapper for chunked encoding) so=
 this does not give us any code removal and we still need to maintain it. I=
 don=E2=80=99t understand why we need to rush it as there is no real reason=
 for that.<br>
<br>
Yes and no. Having internal uses only down the road is significantly<br>
easier to deal with than having to support this from a userland<br>
perspective. There is some time to think about it and make it cleaner<br>
or safer to be used for the purpose of fopen/file_get_contents like<br>
usages. But the select issues may remain, not sure yet. I don&#39;t think<b=
r>
this is something that can&#39;t be solved.<br></blockquote><div><br></div>=
<div>I actually resolved that select issue (if it&#39;s what I think it is =
- limitation using select on filtered streams which I got rid of) in the cu=
rrent master so it will be part of 8.6. See=C2=A0<a href=3D"https://github.=
com/php/php-src/pull/20540">https://github.com/php/php-src/pull/20540</a> .=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; Also we cannot just decide not to deprecate it in RC. We would need ex=
tra approval from RM and then new RFC. We had exactly this sort of situatio=
n last year with __sleep and it was huge pain to change. It also took lots =
of our time that we could use for much more important stuff.<br>
<br>
I hear you.<br>
<br>
Important has very different lists depending who we talk to. And<br>
everyone has time when it is possible, being paid to do it or in their<br>
free time. Cumulated time to deal with something we know is broken and<br>
we could fix in a decade or more surely used an order of magnitude<br>
time for too many people than reveriting a deprecation or adapting it.<br>
Even if it happens some RMs will need to deal with it, but you and<br>
others are not alone, dropping a mail here does not hurt and I am sure<br>
some, or I when I know the area, can jump in too. Communication is<br>
sometimes hard but amazingly helpful :).<br><br></blockquote><div><br></div=
><div>The problem is that there wasn&#39;t enough time to properly investig=
ate if the things can be improved on the C side. There was just some bug an=
d then immediate proposal to deprecate it without first not even realising =
that it&#39;s used by chunked encdoing which I needed to point out. Then th=
e idea was to deprecate it for user space only which I actually wasn&#39;t =
against as I assumed there was a proper research into the the usage but tha=
t wasn&#39;t the case because Nicolas then pointed out that it is used in S=
ymfony but the deprecation proposal didn&#39;t get removed.</div><div><br><=
/div><div>What I think is that deprecation should be proposed only if there=
 a deep knowledge of the problem and the context which I&#39;m not sure is =
the case here (and in some other proposals as well).</div><div><br></div><d=
iv>Kind regards,</div><div><br></div><div>Jakub</div></div></div>

--0000000000005b7e4c0657add410--