Hey Timon, On Fri, 13 May 2022 at 15:33, Timon de Groot <tdegroo...@gmail.com> wrote:
> 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 I went with "NO" here for various reasons: 1. usage of `JSON_PRETTY_PRINT` is already rare enough to make the relevance of this parameter almost null 2. complicates an API signature for a very tiny detail 3. if the problem is linting/preferences, have your favorite linter process the file in the way you deem most appropriate Doesn't need to live in php-src. Greets, Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/
