rfc:parse_str_alternative

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Last revisionBoth sides next revision
rfc:parse_str_alternative [2021/08/06 19:26] – Change to http_parse_query dharmanrfc:parse_str_alternative [2021/08/06 19:37] dharman
Line 34: Line 34:
 echo $output['arr'][1]; // baz echo $output['arr'][1]; // baz
 </PHP> </PHP>
 +
 +
 +===== 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/object. What would such API look like? What functionality is missing currently from PHP? Do we need such API in core or can we just expose a function like %%http_parse_query()%% and let the rest be implemented in userland?
  
 ===== Future Scope ===== ===== Future Scope =====
rfc/parse_str_alternative.txt · Last modified: 2022/05/21 14:03 by dharman