Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130233
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
 <83238ad3-c844-4457-dfb3-11321787e022@php.net> <CAH5C8xUOEkfQ6u8AxuV8UGjWU0h7goDsvWa9QQmANhNdU=Dwhw@mail.gmail.com>
 <CAOV5rgZ1LTVf9PBpfQekahmESo=KXE=RVrpeUXrbqxG4OSDMnQ@mail.gmail.com>
 <d6a46bb627a9545e621f37e83c0441e5@glaive.pro> <CAOV5rgZGKJEo+jV7q-qQFB59CXhfNwadYPDbm70e_F+1v=Fgng@mail.gmail.com>
 <CAH5C8xWwcNC3z=FxQZiN2r1aZ1FgriVNAtdw+YwhaN4S2joyzw@mail.gmail.com>
 <CAOV5rgaLX9s-=WZZgxoTE4wmWEzL9mZUF-d8bzGrN3BQDU7i3w@mail.gmail.com>
 <CAOV5rgY3+PrOk2sH0iZ2ne1wg1WVzW4evh6qwu1nyq68tMH-9A@mail.gmail.com>
 <CAH5C8xUEBtywOxgV4zgHVhdzO0KoFejtp04q0LQ+bEAb9nUAvw@mail.gmail.com>
 <CAOV5rgaGjJ+_Qa10pVaCYD_aozV10+UHvLUuVuNOXTz87xHpXA@mail.gmail.com>
 <CAOV5rgZ5y6YF3hLeDAc8TcaOyxkbbF7S0U7R7JMx8Cwff=3QGA@mail.gmail.com>
 <CAH5C8xXAtUN0ja_thZqbN4u4nndr2Lp_SxqZT3E+WN5ASFqWSA@mail.gmail.com> <CAH5C8xVjx1v_CX+5O4sj7CVyJOx4rDASvuqOukWfgupPa=YtGA@mail.gmail.com>
In-Reply-To: <CAH5C8xVjx1v_CX+5O4sj7CVyJOx4rDASvuqOukWfgupPa=YtGA@mail.gmail.com>
Date: Tue, 3 Mar 2026 10:24:31 +0100
Message-ID: <CAOV5rgbsDscEffqiv+c7WThN-Aj0xhL0w5eE13ALY_F5Kmcwmg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fec701064c1b4599"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--000000000000fec701064c1b4599
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi M=C3=A1t=C3=A9,

I just re-read the RFC and I like the updates and precision you've brought
to it here's my review:
For the builders I have nothing more design wise to add this is already
solid. I may nitpick on the *Builder::clear() method name I would have gone
with *Builder::reset() but I presume other developers would go with clear.
Other than that the public API is spot on.

For the Enum, my only concern is that they serve just as flags and their
usage is tightly coupled to the Uri classes. I would add 2 static named
constructors fromUrl and tryFromUrl just for completeness. I believe the
maintenance cost is negligible but the developer DX is improved and allows
for a broader usage of the Enum.

In regards to the path segments usage and constructor I see you already
integrate my Enum suggestions and you have explained why a fully
fledged class is not the right approach. So the current design is already
solid.

Last but not least, The Percent encoding feature should be IMHO improved by
moving the encode/decode methods from being static methods on the URI
classes to becoming public API on the Enum. This would indeed imply
renaming the enum from  Uri\Rfc3986\UriPercentEncodingMode to
Uri\Rfc3986\UriPercentEncoder with two methods encode/decode. Again it
makes for a more self-contained feature and adds to the DX. Developer will
not have to always statically call the URI classes for encoding/decoding
strings as the Enums and their cases already convey the information
correctly.

Overall I believe this is going into the right direction

Regards,
Ignace


On Sun, Mar 1, 2026 at 11:09=E2=80=AFPM M=C3=A1t=C3=A9 Kocsis <kocsismate90=
@gmail.com> wrote:

> Hey Ignace et al,
>
> I have updated the RFC in the past few weeks with a lot of extra info,
> mostly related to path segment handling: I investigated WHATWG URL's
> behavior more thoroughly, and it turned out that path segments are handle=
d
> very interestingly, so there was a significant difference compared
> to RFC 3986 yet again.
>
> Please give the RFC another read, if possible.
>
> Regards,
> M=C3=A1t=C3=A9
>
>

--000000000000fec701064c1b4599
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi M=C3=A1t=C3=A9,<div><br></div><div>I just re-read the R=
FC and I like the updates and precision you&#39;ve brought to it here&#39;s=
 my review:</div><div>For the builders I have nothing more design wise to a=
dd this is already solid. I may nitpick on the *Builder::clear() method nam=
e I would have gone with *Builder::reset() but I presume other developers w=
ould go with clear. Other than that the public API is spot on.</div><div><b=
r></div><div>For the Enum, my only concern is that they serve just as flags=
 and their usage is tightly=C2=A0coupled to the Uri classes. I would add=C2=
=A02 static=C2=A0named constructors fromUrl and tryFromUrl just for complet=
eness. I believe the maintenance cost is negligible=C2=A0but the developer =
DX is improved and allows for a broader usage of the Enum.</div><div><br></=
div><div>In regards to the path segments usage and constructor I see you al=
ready integrate my Enum suggestions and you have explained why=C2=A0a fully=
 fledged=C2=A0class is not the right approach. So the current design is alr=
eady solid.</div><div><br></div><div>Last=C2=A0but not=C2=A0least, The Perc=
ent encoding feature should be IMHO improved by moving the encode/decode me=
thods from being static methods on the URI classes to becoming public API o=
n the Enum. This would indeed imply renaming the enum from=C2=A0 Uri\Rfc398=
6\UriPercentEncodingMode to Uri\Rfc3986\UriPercentEncoder with two methods =
encode/decode. Again it makes for a more self-contained feature and adds to=
 the DX. Developer will not have to always statically call the URI classes =
for encoding/decoding strings as the Enums and their cases already convey t=
he information correctly.</div><div><br></div><div>Overall I believe this i=
s going into the right direction=C2=A0</div><div><br></div><div>Regards,</d=
iv><div>Ignace</div><div><br></div></div><br><div class=3D"gmail_quote gmai=
l_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Mar 1, 202=
6 at 11:09=E2=80=AFPM M=C3=A1t=C3=A9 Kocsis &lt;<a href=3D"mailto:kocsismat=
e90@gmail.com">kocsismate90@gmail.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">Hey =
Ignace et al,<div><br></div><div>I have updated the RFC in the past few wee=
ks with a lot of extra info, mostly related to path segment handling: I inv=
estigated WHATWG URL&#39;s</div><div>behavior more thoroughly, and it turne=
d out that path segments are handled very interestingly, so there was a sig=
nificant difference compared</div><div>to RFC 3986 yet again.</div><div><br=
></div><div>Please give the RFC another read, if possible.</div><div><br></=
div><div>Regards,</div><div>M=C3=A1t=C3=A9</div><div><br></div></div><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr">
</div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div>

--000000000000fec701064c1b4599--