Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130286
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXkpbfyvo0rcnj3vSMW19SH8f9D-Frn5hG5hjtP2iafSA@mail.gmail.com>
 <d5e67274-aef8-445f-9116-3eed2a36f78e@Spark>
In-Reply-To: <d5e67274-aef8-445f-9116-3eed2a36f78e@Spark>
Date: Mon, 9 Mar 2026 22:05:04 +0100
Message-ID: <CAH5C8xXNgLUtdbOj2ZOQGdmqNjctfX0BJWK8SnhfpcR2k7bDdA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Query Parameter Manipulation Support
To: Jordi Kroon <jordikroon@me.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000616e35064c9dc28a"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000616e35064c9dc28a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Jordi,

In the examples you mention the usage of `parse` and `toString`. I assume
> there is no =E2=80=9Cdefault=E2=80=9D and this is a placeholder for one o=
f the given
> implementations. But it=E2=80=99s perhaps better to pick one of for the e=
xamples as
> it suggests it would also exist.
>

Ah, thanks for the info! Most of these were omission in fact, as I forgot
to update the original method names after I unified the two QueryParams
classes.


> When it comes to the implementation I believe it would be nice to also
> have a `getKeys()` method. That would only return the keys.
>
> You do mention the focus is to move away from $_GET. I like the idea, but
> implementing QueryString would still require something like the following=
:
>
> Uri\QueryParams::fromArray($_GET);
>
> If we really want to make `$_GET` obsolete, wouldn=E2=80=99t it be nice t=
o have a
> `fromRequest()` which would directly parse `$_GET` or use
> `$_SERVER["QUERY_STRING=E2=80=9D]`.
>

As far as I can see, Uri\QueryParams::fromArray($_GET); wouldn't be needed.
Do you have any use-case in mind where the suggested
"Uri\QueryParams::parseRfc3986($_SERVER["QUERY_STRING"]);" call wouldn't
work instead? I'm not against adding a fromRequest()
method though if others find it useful (I'm a bit neutral about it). And
I'd probably use a fromCurrentRequest() or a similar name to
highlight the fact that it uses the current request as source.


> 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
> classes in the same namespace are also readonly, it should follow the sam=
e
> principle (also for consistency) I believe.
>

I think the most problematic case is to return a mutable class from a
readonly class (e.g. Uri\Rfc3986\Uri::getQueryParams()). So we should eithe=
r
omit this method, or make Uri\QueryParams readonly indeed.

Regards,
M=C3=A1t=C3=A9

--000000000000616e35064c9dc28a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Jordi,</div><div dir=3D"ltr"><br></div=
><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div><div name=3D"messageBodySection"><div dir=3D"=
auto">
In the examples you mention the usage of `parse` and `toString`. I assume t=
here is no =E2=80=9Cdefault=E2=80=9D and this is a placeholder for one of t=
he given implementations. But it=E2=80=99s perhaps better to pick one of fo=
r the examples as it suggests it would also exist.=C2=A0<br></div></div></d=
iv></blockquote><div><br></div><div>Ah, thanks for the info! Most of these =
were omission in fact, as I forgot to update the original method names afte=
r I unified the two QueryParams classes.</div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div><div name=3D"messageBodySection"=
><div dir=3D"auto">
When it comes to the implementation I believe it would be nice to also have=
 a `getKeys()` method. That would only return the keys.<br>
<br>
You do mention the focus is to move away from $_GET. I like the idea, but i=
mplementing QueryString would still require something like the following:<b=
r></div>
<pre>Uri\QueryParams::fromArray($_GET);</pre>
<div dir=3D"auto">If we really want to make `$_GET` obsolete, wouldn=E2=80=
=99t it be nice to have a `fromRequest()` which would directly parse `$_GET=
` or use `$_SERVER[&quot;QUERY_STRING=E2=80=9D]`.<br></div></div></div></bl=
ockquote><div><br></div><div>As far as I can see, Uri\QueryParams::fromArra=
y($_GET); wouldn&#39;t be needed. Do you have any use-case in mind where th=
e suggested</div><div>&quot;Uri\QueryParams::parseRfc3986($_SERVER[&quot;QU=
ERY_STRING&quot;]);&quot; call wouldn&#39;t work instead? I&#39;m not again=
st adding a fromRequest()</div><div>method though if others find it useful =
(I&#39;m a bit neutral about it). And I&#39;d probably use a fromCurrentReq=
uest() or a similar name to</div><div>highlight the fact that it uses the c=
urrent request as source.</div><div>=C2=A0</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"><div><div name=3D"messageBodySection"><div dir=3D"au=
to">
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 classes =
in the same namespace are also readonly, it should follow the same principl=
e (also for consistency) I believe.</div></div></div></blockquote><div><br>=
</div><div>I think the most problematic case is to return a mutable class f=
rom a readonly class (e.g. Uri\Rfc3986\Uri::getQueryParams()). So we should=
 either</div><div>omit this method, or make Uri\QueryParams readonly indeed=
.</div><div><br></div><div>Regards,</div><div>M=C3=A1t=C3=A9</div><div>=C2=
=A0</div></div></div>

--000000000000616e35064c9dc28a--