Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124666
Precedence: bulk
MIME-Version: 1.0
References: <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <CAEKnhAGqzhwssfUmu_4-8AR-kXp7FH6PPhDdR8X7uPJk-hDiWg@mail.gmail.com>
In-Reply-To: <CAEKnhAGqzhwssfUmu_4-8AR-kXp7FH6PPhDdR8X7uPJk-hDiWg@mail.gmail.com>
Date: Sun, 28 Jul 2024 18:44:53 +0100
Message-ID: <CAEKnhAHT0NN2Fhgvf6RrkhU3CTh9+SHyxzsEdqTNRU14LLNy=A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f950b9061e524dd2"
From: bukka@php.net (Jakub Zelenka)

--000000000000f950b9061e524dd2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Jul 22, 2024 at 11:59=E2=80=AFAM Jakub Zelenka <bukka@php.net> wrot=
e:

> Hi,
>
> On Fri, Jul 19, 2024 at 6:42=E2=80=AFPM Gina P. Banyard <internals@gpb.mo=
e> wrote:
>
>> Hello internals,
>>
>> I have opened the vote for the mega deprecation RFC:
>> https://wiki.php.net/rfc/deprecations_php_true8_4
>> <https://wiki.php.net/rfc/deprecations_php_8_4>
>>
>> Reminder, each vote must be submitted individually.
>>
>>
>
> I voted no on those output handlers as there might be potentially better
> solutions. The whole output stuff needs a closer look so I think we shoul=
d
> wait on this until the review is done.
>

I just had a bit closer look to output handler working and the text is
actually not correct and does not exactly reflect how things works.
Interestingly those two suggested deprecations have associated
functionality that can be seen in the following example:
https://3v4l.org/X91eu

This simple example shows that returning false from the handler have a
special behaviour that can be in no way replaced by throwing exception.
What it does is that it flushes all buffers and does not trigger any error
as far as I see. It also shows that output in the output handler is not
actually always discarded and can be actually used to append text
which might be actually useful functionality for some users.

This is just finding from looking and testing things for around an hour and
half of my time so I might missed other bits. I really think we should
first try to properly understand how the whole output handling works before
doing those sort of deprecations. The RFC should then contain all details
about the edge cases so voters can do informed decision. I would suggest to
take this part out and at least delay it till the next release.

Apology for not taking look sooner but I have been pretty busy until now...

Regards

Jakub

--000000000000f950b9061e524dd2
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"><div dir=3D"l=
tr" class=3D"gmail_attr">On Mon, Jul 22, 2024 at 11:59=E2=80=AFAM Jakub Zel=
enka &lt;<a href=3D"mailto:bukka@php.net">bukka@php.net</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>Hi,</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Fri, Jul 19, 2024 at 6:42=E2=80=AFPM Gina P. Banyard &lt;internals@=
gpb.moe&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Hello internals,<br>
<br>
I have opened the vote for the mega deprecation RFC:<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_true8_4</a><b=
r>
<br>
Reminder, each vote must be submitted individually.<br>
<br></blockquote><br><div><br></div><div>I voted no on those output handler=
s as there might be potentially better solutions. The whole output stuff ne=
eds a closer look so I think we should wait on this until the review is don=
e.<br></div></div></div></blockquote><div><br></div><div>I just had a bit c=
loser look to output handler working and the text is actually not correct a=
nd does not exactly reflect how things works. Interestingly those two sugge=
sted deprecations have associated functionality that can be seen in the fol=
lowing example:=C2=A0<a href=3D"https://3v4l.org/X91eu">https://3v4l.org/X9=
1eu</a></div><div><br></div><div>This simple example shows that returning f=
alse from the handler have a special behaviour that can be in no way replac=
ed by throwing exception. What it does is that it flushes all buffers and d=
oes not trigger any error as far as I see. It also shows that output in the=
 output handler is not actually always discarded and can be actually used t=
o append text</div><div>which might be actually useful functionality for so=
me users.</div><div><br></div><div>This is just finding from looking and te=
sting things for around an hour and half of my time so I might missed other=
 bits. I really think we should first try to properly understand how the wh=
ole output handling works before doing those sort of deprecations. The RFC =
should then contain all details about the edge cases so voters can do infor=
med decision. I would suggest to take this part out and at least delay it t=
ill the next release.</div><div><br></div><div>Apology for not taking look =
sooner but I have been pretty busy until now...</div><div><br></div><div>Re=
gards</div><div><br></div><div>Jakub=C2=A0</div></div></div>

--000000000000f950b9061e524dd2--