Hi Larry,
- 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.
This comes from the WHATWG specification the isSpecial is how it is named
there
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()).
Yes but the return type is not always the same object (Uri and Url are
different so I would be incline not adding a useless interface they are
similar yet different)
There's a count() method, so shouldn't Ur{i|l]QueryParams implement
> Countable?
I tend to agree Countable and IteratoAggregate should be implemented IMHO
- 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?
>
I also do not like the fromArray there are 2 ways to represents query
parameters either you use the WHATWG spec in which case they are pairs or
you use PHP own algorithm (with it's own caveat and have something
resemble the result of parse_str which is destructive by essence. I would
prefer the named constructor to reflect that.
- The sort() method... should it take an optional user callback, or do we
> lock people in to lexical ordering?
>
This is also derived from the WHATWG spec. Adding a callback might be
useful but it really then depends on how you represent each query
parameter/pairs.
- Why both Uri getRawQueryParams() and getQueryParams()? It looks like
> they would return the same value, no? (If not, that should be explained.)
>
Because Uri\Rfc3986\Uri already exposes Uri::getQuery and Uri::getRawQuery.
- It would be quite convenient of set() and append() returned $this,
> allowing them to be chained.
+1
I believe that the structure for the query string is the thing that will
need more explaining. Once it is correctly settled on the rest can easily
be derived from.
my 2 cents.
On Mon, Dec 1, 2025 at 11:22 PM Larry Garfield <[email protected]>
wrote:
> 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
>
