Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130654
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>
 <CAOV5rgbsDscEffqiv+c7WThN-Aj0xhL0w5eE13ALY_F5Kmcwmg@mail.gmail.com>
 <CAH5C8xXXrY5iPuAcL0XXYDoRPh=Tz0m7xhszspNqXnfVmM_aAQ@mail.gmail.com>
 <CAH5C8xVdz8N5J+poc7px5PfU0OC+bDebJWrVdYB30O2z2OB+Fw@mail.gmail.com>
 <e402a7f8-714d-45cb-bf93-f3536667b4c5@app.fastmail.com> <4643495923b044673383e38c68beca73@bastelstu.be>
In-Reply-To: <4643495923b044673383e38c68beca73@bastelstu.be>
Date: Thu, 16 Apr 2026 00:21:56 +0200
Message-ID: <CAOV5rgaqPuuYOBSOcPSELvcNOisgO4z1qNejqEiUutV3Q-72=g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	Larry Garfield <larry@garfieldtech.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000076ca47064f872563"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--00000000000076ca47064f872563
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As far as I am concerned, this brings me back to my earlier suggestion
(with a Polyfill implementation). The name can be changed or improved but I
did go
with an Enum and two public methods encode/decode see
https://github.com/thephpleague/uri-src/pull/186 which to me sounded like:

-  a better DX. which avoid polluting the Uri(l) classes
- allow for an easier transition with an additional polyfill
- properly decouple the Encoding feature from the URI parsing ones.

so am I +1 on this change that I have already expressed which is my biggest
concern over the current RFC proposal

On Wed, Apr 15, 2026 at 10:23=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.=
be> wrote:

> Hi
>
> Am 2026-04-15 22:04, schrieb Larry Garfield:
> > For host type detection, what does a null return signify?  UrlHostType
> > includes an Empty case, which I'd assume would be used in that
> > situation.  And I'd rather have an Empty case on UriHostType as well
> > rather than null, unless someone can make a good argument for using
> > null instead...
>
> An empty host is semantically different from a missing host.
>
> You can check that with the existing functionality in PHP 8.5, where
> `getHost()` is `?string` for both RFC 3986 and WHATWG URL in accordance
> with the respective standards. If `getHostType()` will return `null` if
> `getHost()` returns `null`. The cases of the Ur[il]HostType enums in the
> featured RFC are also pulled straight from the respective
> specifications.
>
> > LeadingSlashPolicy::AddForNonEmtpyRelative is... a mouthful.
> > Self-documenting is fine, but as the example demonstrates it quickly
> > creates super long lines.  That could be a problem in, say, a match()
> > statement, inside a method, where with that enum value as a case you'd
> > be more than halfway across the screen before you get to the executable
> > code for that case.  Is there no way to make that whole thing shorter?
>
> FYI: I've also had little time for this RFC, but I've started discussing
> spinning off the =E2=80=9Cpath segment=E2=80=9D part of the RFC into a de=
dicated RFC
> with Mate off-list a few days ago, similarly to how the query parameters
> part has been spun off because it has become too complicated for a bulk
> RFC.
>
> > I'm not sure how I feel about object methods on the enum.  That would
> > be something like:
> >
> > use Uri\Rfc3986\PercentEncoder;
> >
> > PercentEncoder::Path->encode($someval);
> >
> > Right? [=E2=80=A6]
>
> Yes.
>
> > use Uri\Rfc3986\encode;
> >
> > encode($someval, PercentEncoder::Path);
> >
> > Is about the same length, and with PFA easily pre-configurable, and
> > closer to what is typically seen in the wild today.
>
> FWIW: The enum would also be =E2=80=9Cpre-configurable=E2=80=9D with
> https://wiki.php.net/rfc/partial_function_application_this. Arnaud and I
> are working on a more general version of that RFC based on Bob's
> feedback, but will need to figure out the latest edge cases before
> proposing it.
>
> Best regards
> Tim D=C3=BCsterhus
>

--00000000000076ca47064f872563
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As far as I am concerned, this brings me back to my earlie=
r suggestion (with a Polyfill implementation). The name can be changed or i=
mproved but I did go<div>with an Enum and two public methods encode/decode =
see <a href=3D"https://github.com/thephpleague/uri-src/pull/186">https://gi=
thub.com/thephpleague/uri-src/pull/186</a> which to me sounded like:</div><=
div><br></div><div>-=C2=A0 a better DX. which avoid polluting the Uri(l) cl=
asses</div><div>- allow for an easier transition with an additional=C2=A0po=
lyfill</div><div>- properly decouple the Encoding feature from the URI pars=
ing ones.</div><div><br></div><div>so am I=C2=A0+1 on this change that I ha=
ve already expressed which is my biggest concern over the current RFC propo=
sal</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div di=
r=3D"ltr" class=3D"gmail_attr">On Wed, Apr 15, 2026 at 10:23=E2=80=AFPM Tim=
 D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<=
br>
<br>
Am 2026-04-15 22:04, schrieb Larry Garfield:<br>
&gt; For host type detection, what does a null return signify?=C2=A0 UrlHos=
tType <br>
&gt; includes an Empty case, which I&#39;d assume would be used in that <br=
>
&gt; situation.=C2=A0 And I&#39;d rather have an Empty case on UriHostType =
as well <br>
&gt; rather than null, unless someone can make a good argument for using <b=
r>
&gt; null instead...<br>
<br>
An empty host is semantically different from a missing host.<br>
<br>
You can check that with the existing functionality in PHP 8.5, where <br>
`getHost()` is `?string` for both RFC 3986 and WHATWG URL in accordance <br=
>
with the respective standards. If `getHostType()` will return `null` if <br=
>
`getHost()` returns `null`. The cases of the Ur[il]HostType enums in the <b=
r>
featured RFC are also pulled straight from the respective <br>
specifications.<br>
<br>
&gt; LeadingSlashPolicy::AddForNonEmtpyRelative is... a mouthful.=C2=A0 <br=
>
&gt; Self-documenting is fine, but as the example demonstrates it quickly <=
br>
&gt; creates super long lines.=C2=A0 That could be a problem in, say, a mat=
ch() <br>
&gt; statement, inside a method, where with that enum value as a case you&#=
39;d <br>
&gt; be more than halfway across the screen before you get to the executabl=
e <br>
&gt; code for that case.=C2=A0 Is there no way to make that whole thing sho=
rter?<br>
<br>
FYI: I&#39;ve also had little time for this RFC, but I&#39;ve started discu=
ssing <br>
spinning off the =E2=80=9Cpath segment=E2=80=9D part of the RFC into a dedi=
cated RFC <br>
with Mate off-list a few days ago, similarly to how the query parameters <b=
r>
part has been spun off because it has become too complicated for a bulk <br=
>
RFC.<br>
<br>
&gt; I&#39;m not sure how I feel about object methods on the enum.=C2=A0 Th=
at would <br>
&gt; be something like:<br>
&gt; <br>
&gt; use Uri\Rfc3986\PercentEncoder;<br>
&gt; <br>
&gt; PercentEncoder::Path-&gt;encode($someval);<br>
&gt; <br>
&gt; Right? [=E2=80=A6]<br>
<br>
Yes.<br>
<br>
&gt; use Uri\Rfc3986\encode;<br>
&gt; <br>
&gt; encode($someval, PercentEncoder::Path);<br>
&gt; <br>
&gt; Is about the same length, and with PFA easily pre-configurable, and <b=
r>
&gt; closer to what is typically seen in the wild today.<br>
<br>
FWIW: The enum would also be =E2=80=9Cpre-configurable=E2=80=9D with <br>
<a href=3D"https://wiki.php.net/rfc/partial_function_application_this" rel=
=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/partial_function=
_application_this</a>. Arnaud and I <br>
are working on a more general version of that RFC based on Bob&#39;s <br>
feedback, but will need to figure out the latest edge cases before <br>
proposing it.<br>
<br>
Best regards<br>
Tim D=C3=BCsterhus<br>
</blockquote></div>

--00000000000076ca47064f872563--