Re: Re: [RFC] Add parse_query_string as an alter native to parse_str

From: Date: Fri, 06 Aug 2021 15:06:12 +0000
Subject: Re: Re: [RFC] Add parse_query_string as an alter native to parse_str
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-115644@lists.php.net to get a copy of this message
On Thu, Aug 5, 2021, at 5:21 PM, Kamil Tekiela wrote: > Hi Internals, > > 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. > > Regards, > Kamil I will be voting No on this as is. Not because I'm against improving the query parsing tools; I'm in favor of that. But as noted, this RFC doesn't do enough to improve it. Returning a value and changing the name isn't enough to justify another global method. As others noted, the parsing rules themselves are fugly and need to be improved. More importantly to me, though, it is the year of our lord 2021, and PHP APIs have no business pretending that arrays with possibly-missing values are a data structure. They're a satire of a data structure. If you're parsing a string with known structure into something, that something should be a properly defined object. The new PhpToken is a good example of that shift done well. Don't give me an array where I have to mess around with isset() and crap like that. Give me a properly defined HttpQuery object with named, type-enforced properties and meaningful methods. Give it a parse(string) static method and a __toString() method to convert back to a query string. Anything less is, frankly, not worth the effort. --Larry Garfield

« previous php.internals (#115644) next »