Hey Máté, Nice work, I really appreciate the effort! While adopting Uri I stumbled upon this missing feature as well.
In the examples you mention the usage of `parse` and `toString`. I assume there is no “default” and this is a placeholder for one of the given implementations. But it’s 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 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’t it be nice to have a `fromRequest()` which would directly parse `$_GET` or use `$_SERVER["QUERY_STRING”]`. 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 principle (also for consistency) I believe. Regards, Jordi On 1 Mar 2026 at 11:32 PM +0100, Máté Kocsis <[email protected]>, wrote: > Hey Everyone, > > As I mentioned in a previous email of mine > (https://externals.io/message/129486#130077), > I recently separated the query parameter handling sub-proposal from > https://wiki.php.net/rfc/uri_followup into its own RFC 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 biggest > change > is that now, only a single class would be added: Uri\QueryParams instead of > both an RFC 3986 > and a WHATWG URL compatible implementation. > > The focus of the RFC is now to move away from the usage of the $_GET > superglobal, > which goal comes with two additional expectations: > - the new implementation should have comparable performance to $_GET > - the new implementation should support most capabilities of $_GET (e.g. > arrays) > > The first one is probably straightforward to achieve, the latter one has > fundamental > problems: PHP's feature set (mostly: array support) is not compatible with > the WHATWG URL, > so some behavior likely wouldn't comply with this specification. That's why > the RFC > still has some TBD parts (e.g. Array API), or some contradicting info related > to some getters' and setters' signature/behavior. > > Other than the API itself, the proposal doesn't have many questions, except > one thing: whether the new class should be readonly or not? I tend to make it > readonly, but I'm still not sure (since > this class can be used as a Builder). > > Regards, > Máté > >
