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

From: 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

« previous php.internals (#115212) next »