Re: [RFC] Add json_encode indent parameter
| From: | Marco Pivetta | Date: | Tue, 05 Jul 2022 07:44:59 +0000 |
| Subject: | Re: [RFC] Add json_encode indent parameter | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118195@lists.php.net to get a copy of this message | ||
Hey Timon,
On Fri, 13 May 2022 at 15:33, Timon de Groot <tdegroot96@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/