Hey,
I love to see this RFC. I’ve got a few notes which likely come from me not
understanding the specifications. But I think most users will not have read
them and will not know or care about the differences, right?
1. Query setters and types of their parameter. Quote from the builder example:
```
->setQuery("a=1&b=2"])
->setQueryParams(["a" => 1, "b" => 2]) // Has the same effect as the
setQuery() call above
```
I’d expect the `setQueryParams` to set the particular params that I specified
instead of overriding all the query (which I’d expect `setQuery` to do).
Maybe it would be possible for `setQuery` to accept string, array and instances
of `*QueryParams`? And `setQueryParams` could either be left out or override
just the selected params? As far as I see, there is no equivalent
`withQueryParams` so there’s no precedent on how such a method should work,
right?
Btw I wasn’t able to find docs on the existing Uri classes (had to look it up
in the prev RFC). Is the search broken or are the docs just not there yet?
2. Regarding the interface extraction, is there any difference between the
internal states of `Uri\WhatWg\UrlQueryParams` and
`Uri\Rfc3986\UriQueryParams` objects? I would naively expect not only a common
interface, but a common class. A `QueryParams` that could be supplied to any of
the withers/setters and that would be able to `->toRfc3986QueryString()` or
`->toWhatWgQueryString()` on use not on instantiation.
Similarly with the builders I fail to see why do I need to decide on
`Uri\Rfc3986\UriBuilder` and `Uri\WhatWg\UrlBuilder` at the start instead of
having `Uri\Builder` that could be consumed via `->buildRfc3986Url()` or
`->buildWhatWgUri(). Is that UserInfo thing the whole dealbreaker? To me all
the other parts like specifying host, port and so on seem spec-agnostic until
serialization.
3. I agree with Larry that I’d expect `[‘key1’ => ‘value1’, ‘key2’ =>
‘value2’]` to “just work”. I understand the issue about having multiple entries
with the same keys, but I don’t think I should have to understand that to
successfully build queries.
Maybe another method like `bestEffortFromArray()`could be added that would
supoprt various forms of nested arrays and do whatever is possible to make them
into a query string, similar to how `http_build_query()` does? I know it’s not
perfect, but it would be great to have the new tooling as easy to work with as
the previous, instead of having to reshape your arrays to fit a particular
syntax.
BR,
Juris
