Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130220
Date: Mon, 2 Mar 2026 00:14:11 +0100
To: PHP Internals List <internals@lists.php.net>, 
 =?utf-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>
Message-ID: <d5e67274-aef8-445f-9116-3eed2a36f78e@Spark>
In-Reply-To: <CAH5C8xXkpbfyvo0rcnj3vSMW19SH8f9D-Frn5hG5hjtP2iafSA@mail.gmail.com>
References: <CAH5C8xXkpbfyvo0rcnj3vSMW19SH8f9D-Frn5hG5hjtP2iafSA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Query Parameter Manipulation
 Support
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="69a4c848_78437e35_2aa"
From: jordikroon@me.com (Jordi Kroon)

--69a4c848_78437e35_2aa
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hey M=C3=A1t=C3=A9,

Nice work, I really appreciate the effort=21 While adopting Uri I stumble=
d upon this missing feature as well.


In the examples you mention the usage of =60parse=60 and =60toString=60. =
I assume there is no =E2=80=9Cdefault=E2=80=9D and this is a placeholder =
for one of the given implementations. But it=E2=80=99s perhaps better to =
pick one of for the examples as it suggests it would also exist.


When it comes to the implementation I believe it would be nice to also ha=
ve a =60getKeys()=60 method. That would only return the keys.

You do mention the focus is to move away from =24=5FGET. I like the idea,=
 but implementing QueryString would still require something like the foll=
owing:
Uri=5CQueryParams::fromArray(=24=5FGET);
If we really want to make =60=24=5FGET=60 obsolete, wouldn=E2=80=99t it b=
e nice to have a =60fromRequest()=60 which would directly parse =60=24=5F=
GET=60 or use =60=24=5FSERVER=5B=22QUERY=5FSTRING=E2=80=9D=5D=60.

As for whether or not this should be a readonly class. I think it should =
be. The class itself is following various specs. And since all other clas=
ses in the same namespace are also readonly, it should follow the same pr=
inciple (also for consistency) I believe.

Regards,
Jordi
On 1 Mar 2026 at 11:32=E2=80=AFPM +0100, M=C3=A1t=C3=A9 Kocsis <kocsismat=
e90=40gmail.com>, wrote:
> Hey Everyone,
>
> As I mentioned in a previous email of mine (https://externals.io/messag=
e/129486=23130077),
> I recently separated the query parameter handling sub-proposal from=C2=A0=
https://wiki.php.net/rfc/uri=5Ffollowup into its own R=46C because it was=
 way too complex.
> Therefore I'm officially opening its discussion.
>
> After the separation, I reworked the proposal quite a lot: the single b=
iggest change
> is that now, only a single class would be added: Uri=5CQueryParams inst=
ead of both an R=46C 3986
> and a WHATWG URL compatible implementation.
>
> The focus of the R=46C is now to move away from the usage of the =24=5F=
GET superglobal,
> which goal comes with two additional expectations:
> - the new implementation should have comparable performance to =24=5FGE=
T
> - the new implementation should support most capabilities of =24=5FGET =
(e.g. arrays)
>
> The first one is probably straightforward to achieve, the latter one ha=
s fundamental
> problems: PHP's feature set (mostly: array support) is not compatible w=
ith the WHATWG URL,
> so some behavior likely wouldn't comply with this specification. That's=
 why the R=46C
> still has some TBD parts (e.g. Array API), or some contradicting info r=
elated to some getters' and setters'=C2=A0signature/behavior.
>
> Other than the=C2=A0API itself, the proposal doesn't have many question=
s, except one thing: whether the new class should be readonly or not=3F I=
 tend to make it readonly, but I'm still not sure (since
> this class can be used as a Builder).
>
> Regards,
> M=C3=A1t=C3=A9
>
>

--69a4c848_78437e35_2aa
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>
<div dir=3D=22auto=22>Hey M=C3=A1t=C3=A9,<br />
<br />
Nice work, I really appreciate the effort=21 While adopting Uri I stumble=
d upon this missing feature as well.<br />
<br />
<br />
In the examples you mention the usage of =60parse=60 and =60toString=60. =
I assume there is no =E2=80=9Cdefault=E2=80=9D and this is a placeholder =
for one of the given implementations. But it=E2=80=99s perhaps better to =
pick one of for the examples as it suggests it would also exist.&=23160;<=
br />
<br />
<br />
When it comes to the implementation I believe it would be nice to also ha=
ve a =60getKeys()=60 method. That would only return the keys.<br />
<br />
You do mention the focus is to move away from =24=5FGET. I like the idea,=
 but implementing QueryString would still require something like the foll=
owing:<br /></div>
<pre>Uri=5CQueryParams::fromArray(=24=5FGET);</pre>
<div dir=3D=22auto=22>If we really want to make =60=24=5FGET=60 obsolete,=
 wouldn=E2=80=99t it be nice to have a =60fromRequest()=60 which would di=
rectly parse =60=24=5FGET=60 or use =60=24=5FSERVER=5B=22QUERY=5FSTRING=E2=
=80=9D=5D=60.&=23160;<br />
<br />
As for whether or not this should be a readonly class. I think it should =
be. The class itself is following various specs. And since all other clas=
ses in the same namespace are also readonly, it should follow the same pr=
inciple (also for consistency) I believe.</div>
</div>
<div name=3D=22messageSignatureSection=22><br />
Regards,
<div dir=3D=22auto=22>Jordi</div>
</div>
<div name=3D=22messageReplySection=22>On 1 Mar 2026 at 11:32=E2=80=AFPM +=
0100, M=C3=A1t=C3=A9 Kocsis &lt;kocsismate90=40gmail.com&gt;, wrote:<br /=
>
<blockquote type=3D=22cite=22 style=3D=22border-left-color: grey; border-=
left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left:=
 10px;=22>
<div dir=3D=22ltr=22>Hey Everyone,
<div><br /></div>
<div>As I mentioned in a previous email of mine (<a href=3D=22https://ext=
ernals.io/message/129486=23130077=22>https://externals.io/message/129486=23=
130077</a>),</div>
<div>I recently separated the query parameter handling sub-proposal from&=
=23160;<a href=3D=22https://wiki.php.net/rfc/uri=5Ffollowup=22>https://wi=
ki.php.net/rfc/uri=5Ffollowup</a> into its own R=46C because it was way t=
oo complex.</div>
<div>Therefore I'm officially opening its discussion.</div>
<div><br /></div>
<div>After the separation, I reworked the proposal quite a lot: the singl=
e biggest change</div>
<div>is that now, only a single class would be added: Uri=5CQueryParams i=
nstead of both an R=46C 3986</div>
<div>and a WHATWG URL compatible implementation.</div>
<div><br /></div>
<div>The focus of the R=46C is now to move away from the usage of the =24=
=5FGET superglobal,</div>
<div>which goal comes with two additional expectations:</div>
<div>- the new implementation should have comparable performance to =24=5F=
GET</div>
<div>- the new implementation should support most capabilities of =24=5FG=
ET (e.g. arrays)</div>
<div><br /></div>
<div>The first one is probably straightforward to achieve, the latter one=
 has fundamental</div>
<div>problems: PHP's feature set (mostly: array support) is not compatibl=
e with the WHATWG URL,</div>
<div>so some behavior likely wouldn't comply with this specification. Tha=
t's why the R=46C</div>
<div>still has some TBD parts (e.g. Array API), or some contradicting inf=
o related to some getters' and setters'&=23160;signature/behavior.</div>
<div><br /></div>
<div>Other than the&=23160;API itself, the proposal doesn't have many que=
stions, except one thing: whether the new class should be readonly or not=
=3F I tend to make it readonly, but I'm still not sure (since</div>
<div>this class can be used as a Builder).</div>
<div><br /></div>
<div>Regards,</div>
<div>M=C3=A1t=C3=A9</div>
<div><br /></div>
<div><br /></div>
</div>
</blockquote>
</div>
</body>
</html>

--69a4c848_78437e35_2aa--