# [RFC] Add parse_query_string as an alternative to parse_str - Thread: https://externals.io/message/115081 - Original archive: https://news-web.php.net/php.internals/115081 - Started by Kamil Tekiela on 2021-06-23T22:02:30+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #115081 — Kamil Tekiela — 2021-06-23T22:02:30+00:00 URL: https://externals.io/message/115081#115081 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 — Sara Golemon — 2021-06-23T23:19:55+00:00 URL: https://externals.io/message/115081#115083 · In reply to: #115081 > 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 — David Rodrigues — 2021-06-24T00:01:56+00:00 URL: https://externals.io/message/115081#115086 · In reply to: #115083 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 escreveu: > On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela > wrote: > > > […] > it > > […] > 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 — Nikita Popov — 2021-06-29T14:55:46+00:00 URL: https://externals.io/message/115081#115212 · In reply to: #115083 > On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela > wrote: > > > […] > it > > […] > 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 — Kamil Tekiela — 2021-07-19T11:04:28+00:00 URL: https://externals.io/message/115081#115487 · In reply to: #115212 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