Re: [PHP-DEV] Revisiting Userland Operator Overloads

My recommendation is to have a base interface for every operator that can be overloaded, so that these can be composed together. AddOverloadInterface { __overloadAdd(): self; } SubOverloadInterface { __overloadSub(): self; } MulOverloadInterface { __overloadMul(): self; } DivOverloadInterface { __

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

Hi Internals, Thanks for all the feedback. I have changed the name to http_parse_query as it looks like more people prefer that name. I have also updated https://wiki.php.net/rfc/parse_str_alternative for 8.2 (sorry for the confusion) and I added open points. I hear two concerns currently about th

Re: [PHP-DEV] Revisiting Userland Operator Overloads

On Fri, Aug 6, 2021, at 11:34 AM, Jordan LeDoux wrote: > Hey all, > > I contacted Jan a few days ago to ask if they were going to try again for > their RFC, but I wanted to get a quick temperature check on this. > > I would like to work on this RFC for 8.2, and after going through previous > disc

[PHP-DEV] Revisiting Userland Operator Overloads

Hey all, I contacted Jan a few days ago to ask if they were going to try again for their RFC, but I wanted to get a quick temperature check on this. I would like to work on this RFC for 8.2, and after going through previous discussions on the topic, I feel like the right place to start is to limi

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

On 06/08/2021 16:06, Larry Garfield wrote: 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 effo

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative toparse_str

On 06.08.2021 at 15:20, Rowan Tommins wrote: > On 06/08/2021 12:12, Kamil Tekiela wrote: > >> Perhaps, instead of adjusting this behaviour only for the new >> function, we >> could remove this behaviour as a whole, given that it is a remainder >> of the >> long-forgotten register globals? I don't

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

On 06.08.2021 at 16:09, Scott Arciszewski wrote: > http_parse_query() would get my vote (if I had vote karma :P) You have a php.net account[1], so you are supposed to have voting karma. :) [1] -- Christoph M. Becker -- PHP Internals - PHP Runtime Developmen

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

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 bec

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

http_parse_query() would get my vote (if I had vote karma :P) On Fri, Aug 6, 2021 at 4:05 AM Mike Schinkel wrote: > > On Aug 6, 2021, at 3:51 AM, Aleksander Machniak wrote: > > > > I agree about the _string suffix removal. However, I know we have > > parse_url() already, but parse_query() might

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

On 06/08/2021 12:12, Kamil Tekiela wrote: Perhaps, instead of adjusting this behaviour only for the new function, we could remove this behaviour as a whole, given that it is a remainder of the long-forgotten register globals? I don't see any use for it anymore Changing behaviour like this is t

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

btw why isn't foo.bar=123 decoded to array("foo.bar"=>123); ? > this looks pretty bad to me https://3v4l.org/6Wa23 Hi Hans, This is because variables in PHP that contain the concatenation operator or space are much more difficult to access. See https://3v4l.org/vUBWK As the primary purpose of p

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

btw why isn't foo.bar=123 decoded to array("foo.bar"=>123); ? this looks pretty bad to me https://3v4l.org/6Wa23 On Fri, 6 Aug 2021 at 10:29, Peter Bowyer wrote: > On Fri, 6 Aug 2021 at 08:18, ignace nyamagana butera > wrote: > > > I read your RFC and I understand the intent in improving the c

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

> I agree about the _string suffix removal. However, I know we have > parse_url() already, but parse_query() might be too generic. I would > suggest adding "http" to the name. And as we already have > http_build_query() I would rather see http_parse_query(). > +1 for http_parse_query() as it sound

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

On Fri, 6 Aug 2021 at 08:18, ignace nyamagana butera wrote: > I read your RFC and I understand the intent in improving the current > parse_str function behaviour by introducing a new function to > avoid possible breakage, > However I feel that we are missing a chance to also improve how parse_str

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

> On Aug 6, 2021, at 3:51 AM, Aleksander Machniak wrote: > > I agree about the _string suffix removal. However, I know we have > parse_url() already, but parse_query() might be too generic. I would > suggest adding "http" to the name. And as we already have > http_build_query() I would rather see

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

On 06.08.2021 09:45, Mike Schinkel wrote: > I too would appreciate having a function in the PHP library that returns an > array and that is named more intuitively than parse_str(). > > However, I would suggest naming it `parse_query()` instead of > `parse_query_string()` as `_string()` is redund

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

> On Aug 5, 2021, at 6:21 PM, Kamil Tekiela wrote: > > 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. I too would appreciate having a function in the PHP library that returns an array

[PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

Hi Kamil Tekiela, I read your RFC and I understand the intent in improving the current parse_str function behaviour by introducing a new function to avoid possible breakage, However I feel that we are missing a chance to also improve how parse_str algorithm is currently used, we could or should (?