Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118195
MIME-Version: 1.0
References: <7d72b5c1-d19b-8734-57e0-f02c402b09c2@gmail.com>
In-Reply-To: <7d72b5c1-d19b-8734-57e0-f02c402b09c2@gmail.com>
Date: Tue, 5 Jul 2022 09:44:59 +0200
Message-ID: <CADyq6s+Wh4tzW_ko=rYe=WNF7OKqgOAHFO3wBX09xmOnM5D9Pw@mail.gmail.com>
To: Timon de Groot <tdegroot96@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004931bc05e30a0823"
Subject: Re: [PHP-DEV] [RFC] Add json_encode indent parameter
From: ocramius@gmail.com (Marco Pivetta)

--0000000000004931bc05e30a0823
Content-Type: text/plain; charset="UTF-8"

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/

--0000000000004931bc05e30a0823--