Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130735
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@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>
 <1fee2f46-27b7-4eb2-908f-b38f8c78d8c9@bastelstu.be> <CAH5C8xVxMt3n-GbK5ac0E1QjLF_S9-ZhPrnOtcMoh-BQxMBwRQ@mail.gmail.com>
 <CAH5C8xWAUcforsq4UyjbJt_RU3KVqtdjB3gGGHTRxvCevEwigg@mail.gmail.com>
In-Reply-To: <CAH5C8xWAUcforsq4UyjbJt_RU3KVqtdjB3gGGHTRxvCevEwigg@mail.gmail.com>
Date: Fri, 1 May 2026 15:57:37 +0200
Message-ID: <CAOV5rgahSkdPmOpsAgNCUcshTZeYdf9AY8XK0C33rBGLcqeLxg@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="0000000000004d32090650c1f777"
From: nyamsprod@gmail.com (ignace nyamagana butera)

--0000000000004d32090650c1f777
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi M=C3=A1t=C3=A9 and all,

I have no issue with the usage of namespaced functions, on the contrary I
think that they do give a better understanding of the intended API usage.
It is a self contained feature which is fully decoupled from the main URI
classes with 0 side-effects.

My main goal has always been to provide a better UX over having static
methods on the main URI classes.

As you pointed out, adding percent-decoding in a later stage seems
reasonable to me, if we can find a way in the meantime to remove the
mis-usage
or mis-understanding you highlighted then at that point adding a new
function will then be a no-brainer. So there will be no pushed back from my
part around
this change.

In the meantime, I have already updated my polyfill to be inline with your
last changes. As I said earlier, the fact that the introduced Enums can not
be instantiated
from an URI makes their presence in the polyfill required but incomplete as
they can not be used before PHP8.6 since the URI classes are final and no
named
constructors can be attached to them to allow their instantiation from an
actual URI instance.

see https://github.com/thephpleague/uri-src/pull/170/changes

Looking forward to your call for voting and its outcome.

Regards,
Ignace

On Thu, Apr 30, 2026 at 9:19=E2=80=AFPM M=C3=A1t=C3=A9 Kocsis <kocsismate90=
@gmail.com> wrote:

> Hi Ignace, Tim et al.,
>
> I've finished updating the RFC once again, after some private discussion
> with Tim:
>
> It turned out that the percent-decoding feature as proposed would have le=
d
> to confusing behavior
> in some cases. In order to avoid this, I ultimately removed the
> percent-decoding support from the
> proposal. In the same time, I pivoted from the "instance methods on an
> enum=E2=80=9D based approach
> to a simple namespaced function based solution, because the enums would
> only ever have a single
> method (even if decoding support is added later, possibly not all the
> (Uri|Url)PercentEncoder enum cases
> would be applicable for decoding). Let me know if this doesn't work for
> you, TBH adding namespaced
> functions was my least favorite solution, but I didn't have any
> significantly better idea which would have had
> the potential to gain traction.
>
> I have called out one example in the RFC (
> https://wiki.php.net/rfc/uri_followup#percent-encoding_support) which
> would be problematic if we had a Uri\Rfc3986\uri_percent_decode()
> function, so let me copy-paste it here for reference:
>
> $uri =3D new Uri\Rfc3986\Uri("https://example.com/?a=3Db%26c");  // The q=
uery
> is the percent-encoded form of "a=3Db&c=3Dd"
>
> echo Uri\Rfc3986\uri_percent_decode(
>     $uri->getQuery(),
>     Uri\Rfc3986\UriPercentEncodingMode::Query
> );
>                            // a=3Db&c
>
> The result is probably not what we expected, because percent-decoding
> changed the meaning of the query component:
> - Originally, the query contained a parameter =E2=80=9Ca=E2=80=9D with va=
lue =E2=80=9Cb%26c=E2=80=9D
> (=E2=80=9Cb&c=E2=80=9D)
> - Now, there is a parameter =E2=80=9Ca=E2=80=9D with value =E2=80=9Cb=E2=
=80=9D, as well as a parameter =E2=80=9Cc=E2=80=9D
> without value
>
> And I'm now attempting once again to announce my intention to start the
> vote:
> If no significant issue comes up this time, then I'll start the vote next
> Tuesday evening (according to UTC).
>
> Regards,
> M=C3=A1t=C3=A9
>
>

--0000000000004d32090650c1f777
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi M=C3=A1t=C3=A9 and all,<div><br></div><div>I have no is=
sue with the usage of namespaced functions, on the=C2=A0contrary I think th=
at they do give=C2=A0a better understanding of the=C2=A0intended API usage.=
</div><div>It is a self contained feature which is fully decoupled from the=
 main URI classes with 0 side-effects.</div><div><br></div><div>My main goa=
l has=C2=A0always been to provide a better UX over having static methods on=
 the main URI classes.=C2=A0</div><div><br></div><div>As you pointed out, a=
dding percent-decoding in a later stage seems reasonable to me, if we can f=
ind a way in the meantime to remove the mis-usage</div><div>or mis-understa=
nding you highlighted then at that point adding a new function=C2=A0will th=
en be a no-brainer. So there will be no pushed back from my part around</di=
v><div>this change.</div><div><br></div><div>In the meantime, I have alread=
y updated my polyfill to be inline with your last changes. As I said earlie=
r, the fact that the introduced Enums can not be instantiated</div><div>fro=
m an URI makes their presence in the polyfill required but incomplete as th=
ey can not be used before PHP8.6 since the URI classes are final and no nam=
ed</div><div>constructors can be attached to them to allow their instantiat=
ion from an actual URI instance.=C2=A0</div><div><br></div><div>see=C2=A0<a=
 href=3D"https://github.com/thephpleague/uri-src/pull/170/changes">https://=
github.com/thephpleague/uri-src/pull/170/changes</a></div><div><br></div><d=
iv>Looking forward to your call for voting and its outcome.</div><div><br><=
/div><div>Regards,</div><div>Ignace</div></div><br><div class=3D"gmail_quot=
e gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr =
30, 2026 at 9:19=E2=80=AFPM M=C3=A1t=C3=A9 Kocsis &lt;<a href=3D"mailto:koc=
sismate90@gmail.com">kocsismate90@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr=
">Hi Ignace, Tim et al.,<div><br></div><div>I&#39;ve finished updating the =
RFC once again, after some private discussion with Tim:</div><div><br></div=
><div>It turned out that the percent-decoding feature as proposed would hav=
e led to confusing behavior</div><div>in some cases. In order to avoid this=
, I ultimately removed the percent-decoding support from the</div><div>prop=
osal. In the same time, I pivoted from the &quot;instance methods on an enu=
m=E2=80=9D based approach</div><div>to a simple namespaced function based s=
olution, because the enums would only ever have a single</div><div>method (=
even if decoding support is added later, possibly not all the (Uri|Url)Perc=
entEncoder enum cases</div><div>would be applicable for decoding). Let me k=
now if this doesn&#39;t work for you, TBH adding namespaced</div><div>funct=
ions was my least favorite solution, but I didn&#39;t have any significantl=
y better idea which would have had</div><div>the potential to gain traction=
.</div><div><br></div><div>I have called out one example in the RFC (<a hre=
f=3D"https://wiki.php.net/rfc/uri_followup#percent-encoding_support" target=
=3D"_blank">https://wiki.php.net/rfc/uri_followup#percent-encoding_support<=
/a>) which</div><div>would be problematic if we had a Uri\Rfc3986\uri_perce=
nt_decode() function, so let me copy-paste it here for reference:</div><div=
><br></div><div>$uri =3D new Uri\Rfc3986\Uri(&quot;<a href=3D"https://examp=
le.com/?a=3Db%26c" target=3D"_blank">https://example.com/?a=3Db%26c</a>&quo=
t;); =C2=A0// The query is the percent-encoded form of &quot;a=3Db&amp;c=3D=
d&quot;<br><br>echo Uri\Rfc3986\uri_percent_decode(<br>=C2=A0 =C2=A0 $uri-&=
gt;getQuery(),<br>=C2=A0 =C2=A0 Uri\Rfc3986\UriPercentEncodingMode::Query<b=
r>);=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// a=3Db&amp;c</=
div><div><br></div><div>The result is probably not what we expected, becaus=
e percent-decoding changed the meaning of the query component:<br>- Origina=
lly, the query contained a parameter =E2=80=9Ca=E2=80=9D with value =E2=80=
=9Cb%26c=E2=80=9D (=E2=80=9Cb&amp;c=E2=80=9D)<br>- Now, there is a paramete=
r =E2=80=9Ca=E2=80=9D with value =E2=80=9Cb=E2=80=9D, as well as a paramete=
r =E2=80=9Cc=E2=80=9D without value</div><div><br></div><div>And I&#39;m no=
w attempting once again to announce=C2=A0my intention=C2=A0to start the vot=
e:</div><div>If no significant issue comes up this time, then I&#39;ll star=
t the vote next Tuesday evening (according to UTC).</div><div><br></div><di=
v>Regards,</div><div>M=C3=A1t=C3=A9</div><div><br></div></div><div class=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">
</blockquote></div>
</div>
</blockquote></div>

--0000000000004d32090650c1f777--