Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129316
Precedence: list
MIME-Version: 1.0
References: <CAEKnhAEO8w0GJXTVyH_nwK8nGQGdJcNNkGOPMnYDVrcsNGrm4A@mail.gmail.com>
 <dfe7ede5-c69d-4802-bc6e-faaf35dcb980@app.fastmail.com>
In-Reply-To: <dfe7ede5-c69d-4802-bc6e-faaf35dcb980@app.fastmail.com>
Date: Wed, 19 Nov 2025 23:41:27 +0100
Message-ID: <CAEKnhAFWFgoWFR5716nVGrUkANuw+nXNCjycC1kC=xgsFbGfDg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Stream Error Handling Improvements
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009a5fbe0643fa4816"
From: bukka@php.net (Jakub Zelenka)

--0000000000009a5fbe0643fa4816
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Nov 19, 2025 at 5:35=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> On Tue, Nov 18, 2025, at 12:38 PM, Jakub Zelenka wrote:
> > Hello,
> >
> > I would like to introduce a new stream error handling RFC that is part
> > of my stream evolution work (PHP Foundation project funded by Sovereign
> > Tech Fund) :
> >
> > https://wiki.php.net/rfc/stream_errors
> >
> > Kind regards,
> >
> > Jakub
>
> HI Jakub.
>
> I agree with what others have said so far.  I'm going to ask a little bit
> further, though.
>
> AIUI, there's two main issues with the stream API:
>
> 1. It's very inconsistent.
> 2. It's very clunky, non-obvious, and hard to use if you don't know
> exactly what you're doing.
>
> This RFC seems to be addressing the first point, which is fine.  However,
> should we be trying to smooth out the current unpleasant API, or should t=
he
> effort be put toward a more intuitive API that is smoother from the start=
?
> This RFC could be a stepping stone toward that, I'm not sure, but if so
> that's not clear to me.
>
> Are there any longer term plans here for a more complete stream overhaul?
>
>
This RFC is part of the bigger effort to address various stream issues and
provide other stream related improvements that I selected based on my TODO
list. You can see more detailed description of the whole scope in this
foundation blog:
https://thephp.foundation/blog/2025/10/30/php-streams-evolution/ .

The overhaul of the whole API is out of scope as there are lots of unknowns
and would require longer migration. It is thus harder to deliver in the
selected time frame. It doesn't mean that it won't happen. It's just out of
scope for this block of work and I don't have specific plans for it.

Kind regards,

Jakub

--0000000000009a5fbe0643fa4816
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 Wed, Nov 19, 2025 at 5:35=
=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">la=
rry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">On Tue, Nov 18, 2025, at 12:38 PM, Jakub Zelenka wrote:=
<br>
&gt; Hello,<br>
&gt;<br>
&gt; I would like to introduce a new stream error handling RFC that is part=
 <br>
&gt; of my stream evolution work (PHP Foundation project funded by Sovereig=
n <br>
&gt; Tech Fund) :<br>
&gt;<br>
&gt; <a href=3D"https://wiki.php.net/rfc/stream_errors" rel=3D"noreferrer" =
target=3D"_blank">https://wiki.php.net/rfc/stream_errors</a><br>
&gt;<br>
&gt; Kind regards,<br>
&gt;<br>
&gt; Jakub<br>
<br>
HI Jakub.<br>
<br>
I agree with what others have said so far.=C2=A0 I&#39;m going to ask a lit=
tle bit further, though.<br>
<br>
AIUI, there&#39;s two main issues with the stream API:<br>
<br>
1. It&#39;s very inconsistent.<br>
2. It&#39;s very clunky, non-obvious, and hard to use if you don&#39;t know=
 exactly what you&#39;re doing.<br>
<br>
This RFC seems to be addressing the first point, which is fine.=C2=A0 Howev=
er, should we be trying to smooth out the current unpleasant API, or should=
 the effort be put toward a more intuitive API that is smoother from the st=
art?=C2=A0 This RFC could be a stepping stone toward that, I&#39;m not sure=
, but if so that&#39;s not clear to me.<br>
<br>
Are there any longer term plans here for a more complete stream overhaul?<b=
r><br></blockquote><div><br></div><div>This RFC is part of the bigger effor=
t to address various stream issues and provide other stream related improve=
ments that I selected based on my TODO list. You can see more detailed desc=
ription of the whole scope in this foundation blog:=C2=A0<a href=3D"https:/=
/thephp.foundation/blog/2025/10/30/php-streams-evolution/">https://thephp.f=
oundation/blog/2025/10/30/php-streams-evolution/</a> .</div><div><br></div>=
<div>The overhaul of the whole API is out of scope as there are lots of unk=
nowns and would require longer migration. It is thus harder to deliver in t=
he selected time frame. It doesn&#39;t mean that it won&#39;t happen. It=
9;s just out of scope for this block of work and I don&#39;t have specific =
plans for it.</div><div><br></div><div>Kind regards,</div><div><br></div><d=
iv>Jakub</div></div></div>

--0000000000009a5fbe0643fa4816--