Hi internals,
Almost a year ago I first proposed my RFC draft to introduce a new
json_encode parameter 'indent'. I have received a lot of feedback on the
change, very insightful. The feedback can be boiled down to:
- Accepting user input characters means you could create invalid JSON.
Do we want that? Should it be complying with the spec[1]?
- Preference for pure types, so int OR string, not both.
So I think I made the change more complex than it should have been and
considered the three options:
1) Accept indent as an int, which will result in N spaces of indent
per indentation level.
2) Accept indent as a string, which will result in string N per
indentation level.
3) Accept indent as an int and indent_char as string, which will
result in N * indent_char per indentation level.
Option 1 seems very simple and feasible while not being confusing.
Option 2 seems feasible, but somewhat more complex, because user input
should be validated.
Option 3 seems very flexible, but in my opinion very confusing at the
same time, while I'm not sure there's even a use case for this level of
flexibility.
I have updated the pull request[2] and RFC[3] to be based on option 1,
as I think this offers clear functionality and I feel like I can't
really go wrong with the indent parameter as an int.
Please let me know what your thoughts are and what needs to be done to
get this RFC going forward!
--
Kind regards,
Timon
[1] https://datatracker.ietf.org/doc/html/rfc4627
[2] https://github.com/php/php-src/pull/7093
[3] https://wiki.php.net/rfc/json_encode_indentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
