Re: [PHP-DEV] Re: [RFC] Add parse_query_string as an alternative to parse_str
Hi Internals, During my research into this topic, I discovered that there exists a multibyte variant of this function in mbstring extension. This raises the question: should we add a corresponding multibyte variant of http_parse_query() to mbstring? Is there any usage in the wild of mb_parse_str()? I have even asked a question on Stack Overflow about this topic https://stackoverflow.com/questions/68761695/can-mb-parse-str-produce-different-results-than-parse-str To me, it doesn't look like parse_str() is useful anymore, but I come from Europe where things happen mostly using a single encoding. I am not aware of any problems that parse_str() might have when it comes to multiple encoding types. In fact, when looking at the whole input/output encoding feature of mbstring I am getting a feeling that this is some niche feature that almost nobody ever uses. While mbstring is useful for dealing with different encodings, I am not sure if it is common for HTTP requests to be encoded with anything else than UTF-8. I would appreciate some input from experts who know more about mbstring and encodings. Regards, Kamil >
Re: [PHP-DEV] readonly properties
>
> >> 2. DateInterval->days
> >>
> >> $interval = (new DateTime())->diff(new DateTime());
> >> var_dump($interval->days); // 0
> >> $refl = (new ReflectionObject($interval))->getProperty('days');
> >> var_dump($refl->isReadOnly()); // false
> >> var_dump($refl->isPublic()); // true
> >> $interval->days = 2;
> >> var_dump($interval->days); // 0
> >>
> > The DateInterval properties are currently implemented as getters/setters
> on
> > some internal state. Some of those are getter-only, but probably not
> fully
> > immutable.
>
> I was referring to the property "days" only as this is a non writable
> value generated on "DateTime->diff".
>
> As you can see in the snipped it doesn't allow to modify days but it
> also doesn't fail which seems wrong to me.
>
> I don't have much knowledge about internals but would it be possible to
> define "public readonly int|false $days" not using getters/setters and
> keep all other properties as it?
>
Hi,
FWIW, I too agree that [$interval->days, $interval->days = 2,
$interval->days] giving [0, 2, 0] without any warning (or
https://3v4l.org/h8Cju for a variation) seems wrong.
Regards,
--
Guilliam Xavier
Re: [PHP-DEV] Re: [RFC] Add parse_query_string as an alternative to parse_str
On Fri, Aug 6, 2021 at 9:43 PM Kamil Tekiela wrote: > 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 this RFC. Please note that my intention > was to provide a simple drop-in replacement. However, I agree that there is > a lot of room for improvement in this area, so I highly appreciate your > comments on how we can best tackle these open points. > I will not open this RFC for voting any time soon, as I want to let the > conversation run through to see what other options/concerns people have. > Please feel free to share your comments on what you think is the right path > to improve this functionality in PHP. > > Regards, > Kamil > Hi, thanks for the RFC. I agree with Rowan in https://externals.io/message/115642 that http_parse_query() should "mirror http_build_query() as closely as possible", notably: - have a similar signature (except for the first parameter `array|object $data` becoming `string $query` and the return type `string` becoming `array`, of course); - do not do name mangling (and for your question "what should happen to mismatched square brackets?": not sure without an example, but I would say "just keep them as is"). Best regards, -- Guilliam Xavier
