Re: [RFC] Add parse_query_string as an alternative to parse_str

I too would appreciate having a function in the PHP library that returns an array and that is named more intuitively than parse_str(). However, I would suggest naming it `parse_query()` instead of `parse_query_string()` as `_string()` is redundant and I see shorter function names being preferable when the intent of the function is clear. I searched for prior art and it appears that Guzzle's PSR7 helper library v1.x had a namespaced parse_query() function: https://github.com/guzzle/psr7/blob/1.x/src/functions.php#L299 <https://github.com/guzzle/psr7/blob/1.x/src/functions.php#L299> I found Psr7\parse_query() being called on GitHub in 840 places using SourceGraph code search: https://sourcegraph.com/search?q=context:global+lang:php+Psr7%5Cparse_query%28+count:all&patternType=literal <https://sourcegraph.com/search?q=context:global+lang:php+Psr7%5Cparse_query%28+count:all&patternType=literal> There was only one (1) place with SourceGraph code search where someone named a function parse_query_string(), and that example did not use parse_query_string() in the same way as your RFC: https://sourcegraph.com/github.com/k0a1a/hotglue2/-/blob/controller.inc.php?L344:1 <https://sourcegraph.com/github.com/k0a1a/hotglue2/-/blob/controller.inc.php?L344:1> My takeaway is that PHP developers will easily be able to understand the intent if named `parse_query()`, especially those who might be familiar with it from Guzzle, and thus there is no need for the redundant `_string()`. And, of course, a parse_query() in the global namespace won't conflict with Guzzle's use because their function is namespaced with Guzzle\Psr7.

Also, +1 to this. -Mike P.S. WordPress has a parse_query() *method* on their WP_Query() class, but as someone who has worked with WordPress for 10+ years even I don't see these two in conflict. One is a method scoped to the solution domain of its class and the other would be a function in PHP's global namespace.

On Thu, Aug 5, 2021, at 5:21 PM, Kamil Tekiela wrote:

I will be voting No on this as is. Not because I'm against improving the query parsing tools; I'm in favor of that. But as noted, this RFC doesn't do enough to improve it. Returning a value and changing the name isn't enough to justify another global method. As others noted, the parsing rules themselves are fugly and need to be improved. More importantly to me, though, it is the year of our lord 2021, and PHP APIs have no business pretending that arrays with possibly-missing values are a data structure. They're a satire of a data structure. If you're parsing a string with known structure into something, that something should be a properly defined object. The new PhpToken is a good example of that shift done well. Don't give me an array where I have to mess around with isset() and crap like that. Give me a properly defined HttpQuery object with named, type-enforced properties and meaningful methods. Give it a parse(string) static method and a __toString() method to convert back to a query string. Anything less is, frankly, not worth the effort. --Larry Garfield