Re: [RFC] [Discussion] Followup Improvements for ext/uri

From: Date: Mon, 01 Dec 2025 22:18:45 +0000
Subject: Re: [RFC] [Discussion] Followup Improvements for ext/uri
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-129493@lists.php.net to get a copy of this message
On Mon, Dec 1, 2025, at 2:50 PM, Máté Kocsis wrote: > Hi Everyone, > > I'd like to introduce my latest RFC that I've been working on for a > while now: https://wiki.php.net/rfc/uri_followup. > > It proposes 5 followup improvements for ext/uri in the following areas: > - URI Building > - Query Parameter Manipulation > - Accessing Path Segments as an Array > - Host Type Detection > - URI Type Detection > - Percent-Encoding and Decoding Support > > I did my best to write an RFC that was at least as extensive as > https://wiki.php.net/rfc/url_parsing_api had become by the end. > Despite > my efforts, > there are still a couple things which need a final decision, or which > need to be polished/improved. Some examples: > > - How to support array/object values for constructing query strings? > (https://wiki.php.net/rfc/uri_followup#type_support) > - How to make the UriQueryParams and UrlQueryParams classes more > interoperable with the query string component (mainly with respect to > percent-encoding)? > (https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding) > - Exactly how the advanced percent-decoding capabilities should work? > Does it make sense to support all the possible modes > (UriPercentEncodingMode) for percent-decoding as well > (https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding_support) > - etc. > > Regards, > Máté Thanks, Máté. Notes as I read through: - I really, really hate the "set" prefix on all the methods. It's a builder object, surely the "set" is implied? $builder->scheme('https')->host('example.com')->path('/foo/bar')->build(); That's nice and easy to read. - It really feels like there's an interface to extract here from the Url/UriBuilder classes. There's literally only one type-specific method (build()). - UriQueryParams::hasWithValue(), could that be just hasValue()? You still need to specify the key anyway, and that's self-evident from the signature. - There's a count() method, so shouldn't Ur{i|l]QueryParams implement Countable? - As above, there really is an interface lurking in UriQueryParams... - Why both Uri getRawQueryParams() and getQueryParams()? It looks like they would return the same value, no? (If not, that should be explained..) - The sort() method... should it take an optional user callback, or do we lock people in to lexical ordering? - It would be quite convenient of set() and append() returned $this, allowing them to be chained. - The fromArray() logic is... totally weird and unexpected and I hate it.. :-) Why can't you support repeated query parameters using nested arrays rather than gumming up all calls with a wonky format? - It's not clear how one would start a new query from scratch, with the private constructor. There doesn't seem to be a justification for the private. I can't see why new UriQueryParams()->set('foo', 'bar') is a bad thing. - Type support: Looks reasonable to me. - The HostType logic seems reasonable to me. - Url::isSpecial() Could we come up with a better name here? "Special" could mean anything unless you know the RFC; it feels like "real escape string" all over again. Some parts of this are over my head as I've not read the relevant RFCs, but overall I do like the direction. --Larry Garfield

« previous php.internals (#129493) next »