Re: [RFC] Add parse_query_string as an alternative to parse_str
| From: | Nikita Popov | Date: | Tue, 29 Jun 2021 14:55:46 +0000 |
| Subject: | Re: [RFC] Add parse_query_string as an alternative to parse_str | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115212@lists.php.net to get a copy of this message | ||
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