[RFC] Add parse_query_string as an alternative to parse_str

  115081
June 23, 2021 22:02 tekiela246@gmail.com (Kamil Tekiela)
Hi Internals,

I would like to propose a new simple RFC that aims to add a new function
called parse_query_string as an alternative to parse_str.

https://wiki.php.net/rfc/parse_str_alternative

The functionality stays the same, only the name and the way of returning
the array changes. While it is a rather insignificant change, I believe it
is one step closer to making PHP cleaner.

Regards,
Kamil
  115083
June 23, 2021 23:19 pollita@php.net (Sara Golemon)
On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela <tekiela246@gmail.com> wrote:

> I would like to propose a new simple RFC that aims to add a new function > called parse_query_string as an alternative to parse_str. > > https://wiki.php.net/rfc/parse_str_alternative > > The functionality stays the same, only the name and the way of returning > the array changes. While it is a rather insignificant change, I believe it > is one step closer to making PHP cleaner. > > There's a potential alternative option that doesn't require adding a new,
parallel function. We can use execute_data->return_value_used to figure out if parse_str() was called with the result assigned to a local var. This is overloady and probably a bad idea, but it's an option. if (ZEND_NUM_ARGS() == 2) { // Put result into by-ref second arg // parse_str($str, $refResult); } else if (EX(return_value_used)) { // Put result into return_value // $result = parse_str($str); } else { // Put result into EG(local_symbol_table) // parse_str($str); php_error(E_DEPRECATED, ...); } Realistically, your approach is probably better simply because it doesn't depend on the assignment as a side-effect, and it'll be good to have a migration route, especially one which gives us a function with, frankly, a much better name. That said, and I'll sound like a broken record here, but this is another case of being something that can be sorted in userspace trivially: function parse_query_string(string $str): array { parse_str($str, $ret); return $ret; } Kinda +/- 0 on it at the moment. I'm less hostile to it than str_contains()/str_left()/str_right()/etc... -Sara
  115086
June 24, 2021 00:01 david.proweb@gmail.com (David Rodrigues)
I really prefer the Sara suggestion, instead of creating a new function
to do the same thing. parse_str($str): array.


Atenciosamente,
David Rodrigues


Em qua., 23 de jun. de 2021 às 20:20, Sara Golemon <pollita@php.net>
escreveu:

> On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela <tekiela246@gmail.com> > wrote: > > > I would like to propose a new simple RFC that aims to add a new function > > called parse_query_string as an alternative to parse_str. > > > > https://wiki.php.net/rfc/parse_str_alternative > > > > The functionality stays the same, only the name and the way of returning > > the array changes. While it is a rather insignificant change, I believe > it > > is one step closer to making PHP cleaner. > > > > > There's a potential alternative option that doesn't require adding a new, > parallel function. We can use execute_data->return_value_used to figure > out if parse_str() was called with the result assigned to a local var. > This is overloady and probably a bad idea, but it's an option. > > if (ZEND_NUM_ARGS() == 2) { > // Put result into by-ref second arg > // parse_str($str, $refResult); > } else if (EX(return_value_used)) { > // Put result into return_value > // $result = parse_str($str); > } else { > // Put result into EG(local_symbol_table) > // parse_str($str); > php_error(E_DEPRECATED, ...); > } > > Realistically, your approach is probably better simply because it doesn't > depend on the assignment as a side-effect, and it'll be good to have a > migration route, especially one which gives us a function with, frankly, a > much better name. > > That said, and I'll sound like a broken record here, but this is another > case of being something that can be sorted in userspace trivially: > > function parse_query_string(string $str): array { > parse_str($str, $ret); > return $ret; > } > > Kinda +/- 0 on it at the moment. I'm less hostile to it than > str_contains()/str_left()/str_right()/etc... > > -Sara >
  115212
June 29, 2021 14:55 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Jun 24, 2021 at 1:20 AM Sara Golemon <pollita@php.net> wrote:

> On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela <tekiela246@gmail.com> > wrote: > > > I would like to propose a new simple RFC that aims to add a new function > > called parse_query_string as an alternative to parse_str. > > > > https://wiki.php.net/rfc/parse_str_alternative > > > > The functionality stays the same, only the name and the way of returning > > the array changes. While it is a rather insignificant change, I believe > it > > is one step closer to making PHP cleaner. > > > > > There's a potential alternative option that doesn't require adding a new, > parallel function. We can use execute_data->return_value_used to figure > out if parse_str() was called with the result assigned to a local var. > This is overloady and probably a bad idea, but it's an option. > > if (ZEND_NUM_ARGS() == 2) { > // Put result into by-ref second arg > // parse_str($str, $refResult); > } else if (EX(return_value_used)) { > // Put result into return_value > // $result = parse_str($str); > } else { > // Put result into EG(local_symbol_table) > // parse_str($str); > php_error(E_DEPRECATED, ...); > }
return_value_used is a hint that cannot always be reliably determined. E.g. if you go through something like call_user_func(), I believe it'll always be set. I think if the observer infrastructure is used, it will also always be set. Using it is okay for optimization, but I don't think we should use this flag to influence behavior. Regards, Nikita
  115487
July 19, 2021 11:04 tekiela246@gmail.com (Kamil Tekiela)
Hi All,

Thanks for the feedback. I decided not to pursue this for PHP 8.1, but I
still think it is a good idea. As Nikita explained Sara's suggestion might
not work at all.
While it is trivially easy to abstract this function in userland the aim is
to clean up PHP. This wouldn't add new functionality to PHP, but rather
provide a cleaner implementation with a self-documenting name.

I don't know when we can start RFCs for PHP 8.2 but I will try to write an
implementation for this RFC in a couple of days and ask for a vote.

Regards,
Kamil

>