RE: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri

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