> On Aug 5, 2021, at 6:21 PM, Kamil Tekiela <tekiela...@gmail.com> wrote:
> 
> I have added implementation for
> https://wiki.php.net/rfc/parse_str_alternative. If there are no other
> comments, I would like to start voting on Saturday.


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.

> On Aug 6, 2021, at 3:17 AM, ignace nyamagana butera <nyamsp...@gmail.com> 
> wrote:
> 
> I feel that we are missing a chance to also improve how parse_str
> algorithm is currently used, we could or should (?) use this opportunity
> to fix some long shortcomings around parse_str.

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.

Reply via email to