Re: [RFC] Add json_encode indent parameter
| From: | Jakub Zelenka | Date: | Sun, 03 Jul 2022 22:01:38 +0000 |
| Subject: | Re: [RFC] Add json_encode indent parameter | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-118164@lists.php.net to get a copy of this message | ||
Hi,
On Fri, May 13, 2022 at 2:33 PM 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!
>
>
I think we can put this RFC to the vote. If the author is to busy I would
like to start voting later this week. It would be a pity not to make it to
feature freeze as it is quite straight forward and the implementation seems
good as well so I guess we don't need to wait extra year. :)
Cheers
Jakub