rfc:parse_str_alternative
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Last revisionBoth sides next revision | ||
rfc:parse_str_alternative [2021/08/06 19:26] – Change to http_parse_query dharman | rfc:parse_str_alternative [2021/08/06 19:37] – dharman | ||
---|---|---|---|
Line 34: | Line 34: | ||
echo $output[' | echo $output[' | ||
</ | </ | ||
+ | |||
+ | |||
+ | ===== Open Points ===== | ||
+ | |||
+ | ==== Should PHP remove name mangling? ==== | ||
+ | |||
+ | As suggested on the mailing list, the name mangling does not serve any purpose anymore. It was a way to simplify variable access when register globals was used. Since PHP 8.0, this functionality is not available anymore, so the question is should we remove the name mangling from PHP parse functions completely (which would require a separate RFC and smart deprecation path) or should we remove it only from the new function? | ||
+ | |||
+ | If we should remove name mangling, what should happen to mismatched square brackets? | ||
+ | |||
+ | ==== Should it be implemented in OOP way instead? ==== | ||
+ | |||
+ | Maybe the replacement should be in a form of a full-fledged class with properties from two-way conversion from string to PHP array/ | ||
===== Future Scope ===== | ===== Future Scope ===== |
rfc/parse_str_alternative.txt · Last modified: 2022/05/21 14:03 by dharman