Re: [RFC] [Discussion] Query Parameter Manipulation Support

From: Date: Sun, 01 Mar 2026 23:14:11 +0000
Subject: Re: [RFC] [Discussion] Query Parameter Manipulation Support
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-130220@lists.php.net to get a copy of this message
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 <kocsismate90@gmail.com>, 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é > >

« previous php.internals (#130220) next »