Re: [RFC] [Discussion] Followup Improvements for ext/uri
| From: | Larry Garfield | 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