Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130285
Precedence: list
MIME-Version: 1.0
References: <CAH5C8xXkpbfyvo0rcnj3vSMW19SH8f9D-Frn5hG5hjtP2iafSA@mail.gmail.com>
 <c68a0b86-cdbe-438e-a6c7-9540e62065c8@bastelstu.be>
In-Reply-To: <c68a0b86-cdbe-438e-a6c7-9540e62065c8@bastelstu.be>
Date: Mon, 9 Mar 2026 21:47:41 +0100
Message-ID: <CAH5C8xVguDVLqFiLoOJThJg8W+VAhwU7D6bqqUS-jX-Fvm=9Tw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Query Parameter Manipulation Support
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003d130b064c9d842f"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000003d130b064c9d842f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Tim,

Thank you for the help, I forgot to link the RFC indeed.

Let me answer your questions:

>
> I don't think it is as necessary to make it readonly as it is with the
> URI classes, since the query parameters class is likely to be used for
> =E2=80=9Clocal modification=E2=80=9D and is less likely to be passed arou=
nd as a value
> object. If efficient copy-on-write is possible internally, then making
> it readonly is the safer choice, of course.
>

Yes, as far as I know from Ilija, it's possible to optimize modification
based on
refcount: if a readonly property which is to be modified has a refcount of
1 and
there's no weakref, it can be safely updated in-place.


> With regard to the RFC text, I've given it a first quick skim and have
> the following notes:
>
> 1. Within the "Relation to the query component" section.
>
> The `$uri =3D new Uri\Rfc3986\Uri("https://example.com?foo=3Da b");` exam=
ple
> is invalid. An URI containing a space is not valid and the `Uri` class
> will throw an exception. Can you double-check that part of the RFC?
> Without looking it up, I suspect that the space should be `%20` for
> RFC3986?
>

Nice catch, I'll review and fix the examples using "a b". It is indeed
incorrect, and %20
should be used instead. as you said.


> 4. Within the "Supported types" section.
>
> =E2=80=9CThe above conversion rules work for both UriQueryParams and
> UrlQueryParams.=E2=80=9D
>
> and the examples also use Uri\Rfc3986\UriQueryParams /
> Uri\WhatWg\UrlQueryParams.
>
> This seems like an oversight from the original implementation, since
> there are no longer separate classes. Can you double-check the entire
> section?
>

I intentionally haven't updated this section yet: because there's important
info about
the difference between how WHATWG specification and uriparser handles null,
so I didn't want to "lose" this (I know it remains in the changelog).


>
> 5. Within the "Array API" section.
>
> This also uses Uri\Rfc3986\UriQueryParams in the examples


Same situation as above, but basically the whole section is a big question
mark:
I couldn't come up with a good enough idea how arrays could be handled
efficiently and ergonomically, and in the same time, how to (mostly) confor=
m
to WHATWG URL.

Some of my problems:
- How should $params->get("foo[bar]") behave? Should we try to parse the
supplied key as an array and return the
nested item if it exists? I suppose, we would internally store the query
params as an array (just like how $_GET does),
so then we would definitely need parsing in order to be able to return item
"bar" stored within array "foo".
- However, what should a $params->append("foo[bar]") call do when the query
param "foo" is already added with a string value?
Should it modify the existing item to be an array (but then how?) or we
should just add "foo[bar]" to the query params as-is?
- How to recompose list parameters? Ideally, we should not append [] to
these parameters (e.g.
"list=3D1&list=3D2" vs "list[]=3D1&list[]=3D2"), and actually, it is not ne=
eded for
arrays in the root level, but as far as I understood,
it's a must-have for nested lists (e.g. "map[list]=3D1&map[list]=3D2" vs.
map[list[]]=3D1&map[list[]]=3D2), otherwise the representation
would be ambiguous for lists with 1 item: "map[list]=3D1" would mean that t=
he
map has a list item with a value of "1". So
we either always have to use the [] suffix for lists, or we should make a
distinction between root-level and nested lists.

I know, most of my questions revolve around parsing the $name parameter,
but I would really want to minimize the number
of times when the $name param has to be parsed run-time so that the
performance is comparable to native array key
lookups. I don't have any idea how much the parsing would cost though...

So at this point, coming up with a sensible plan is needed, and I can fix
most inconsistencies in the RFC afterwards.

Regards,
M=C3=A1t=C3=A9

--0000000000003d130b064c9d842f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hey Tim=
,<div><br></div><div>Thank you for the help, I forgot to link the RFC indee=
d.</div><div><br></div><div>Let me answer your questions:</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"><br>
I don&#39;t think it is as necessary to make it readonly as it is with the =
<br>
URI classes, since the query parameters class is likely to be used for <br>
=E2=80=9Clocal modification=E2=80=9D and is less likely to be passed around=
 as a value <br>
object. If efficient copy-on-write is possible internally, then making <br>
it readonly is the safer choice, of course.<br></blockquote><div><br></div>=
<div>Yes, as far=C2=A0as I know from Ilija, it&#39;s possible to optimize m=
odification based on</div><div>refcount: if a readonly property which is to=
 be modified has a refcount of 1 and</div><div>there&#39;s no weakref, it c=
an be safely updated in-place.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
With regard to the RFC text, I&#39;ve given it a first quick skim and have =
<br>
the following notes:<br>
<br>
1. Within the &quot;Relation to the query component&quot; section.<br>
<br>
The `$uri =3D new Uri\Rfc3986\Uri(&quot;<a href=3D"https://example.com?foo=
=3Da" rel=3D"noreferrer" target=3D"_blank">https://example.com?foo=3Da</a> =
b&quot;);` example <br>
is invalid. An URI containing a space is not valid and the `Uri` class <br>
will throw an exception. Can you double-check that part of the RFC? <br>
Without looking it up, I suspect that the space should be `%20` for RFC3986=
?<br></blockquote><div><br></div><div>Nice catch, I&#39;ll review and fix t=
he examples using &quot;a b&quot;. It is indeed incorrect,=C2=A0and %20</di=
v><div>should be used instead. as you said.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
4. Within the &quot;Supported types&quot; section.<br>
<br>
=E2=80=9CThe above conversion rules work for both UriQueryParams and <br>
UrlQueryParams.=E2=80=9D<br>
<br>
and the examples also use Uri\Rfc3986\UriQueryParams / <br>
Uri\WhatWg\UrlQueryParams.<br>
<br>
This seems like an oversight from the original implementation, since <br>
there are no longer separate classes. Can you double-check the entire <br>
section?<br></blockquote><div><br></div><div>I intentionally haven&#39;t up=
dated this section yet: because there&#39;s important info about</div><div>=
the difference between how WHATWG specification and uriparser handles null,=
</div><div>so I didn&#39;t want to &quot;lose&quot; this (I know it remains=
 in the changelog).</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);p=
adding-left:1ex">
<br>
5. Within the &quot;Array API&quot; section.<br>
<br>
This also uses Uri\Rfc3986\UriQueryParams in the examples</blockquote><div>=
<br></div><div>Same situation as above, but basically the whole section is =
a big question mark:</div><div>I couldn&#39;t come up with a good enough id=
ea how arrays could be handled</div><div>efficiently and ergonomically, and=
 in the same time, how to (mostly) conform</div><div>to WHATWG URL.</div><d=
iv><br></div><div>Some of my problems:</div><div><div>- How should $params-=
&gt;get(&quot;foo[bar]&quot;) behave? Should we try to parse the supplied k=
ey as an array and return the</div><div>nested item if it exists? I suppose=
, we would internally store the query params as an array (just like how $_G=
ET does),</div></div><div>so then we would definitely need parsing in order=
 to be able to return item &quot;bar&quot; stored within array &quot;foo&qu=
ot;.</div><div>- However, what should a $params-&gt;append(&quot;foo[bar]&q=
uot;) call do when the query param &quot;foo&quot; is already added with a =
string value?</div><div>Should it modify the existing item to be an array (=
but then how?) or we should=C2=A0just add &quot;foo[bar]&quot; to the query=
 params as-is?</div><div>- How to recompose list parameters? Ideally, we sh=
ould not append [] to these parameters (e.g.</div><div>&quot;list=3D1&amp;l=
ist=3D2&quot; vs &quot;list[]=3D1&amp;list[]=3D2&quot;), and actually, it i=
s not needed for arrays in the root level, but as far as I understood,</div=
><div>it&#39;s a must-have for nested=C2=A0lists (e.g. &quot;map[list]=3D1&=
amp;map[list]=3D2&quot; vs. map[list[]]=3D1&amp;map[list[]]=3D2), otherwise=
 the representation</div><div>would be ambiguous for lists with 1 item: &qu=
ot;map[list]=3D1&quot; would mean that the map has a list item with a value=
 of &quot;1&quot;. So</div><div>we either always have to use the [] suffix =
for lists, or we should make a distinction between root-level and nested li=
sts.</div><div><br></div><div>I know, most of my questions revolve around p=
arsing the $name parameter, but I would really want to minimize the number<=
/div><div>of times when the $name param has to be parsed run-time so that t=
he performance is comparable to native array key</div><div>lookups. I don&#=
39;t have any idea how much the parsing would cost though...</div><div><br>=
</div><div>So at this point, coming up with a sensible plan is needed, and =
I can fix most inconsistencies in the RFC afterwards.</div><div><br></div><=
div>Regards,</div><div>M=C3=A1t=C3=A9</div><div><br></div><div><br></div></=
div></div>
</div>
</div>

--0000000000003d130b064c9d842f--