Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118164
MIME-Version: 1.0
References: <7d72b5c1-d19b-8734-57e0-f02c402b09c2@gmail.com>
In-Reply-To: <7d72b5c1-d19b-8734-57e0-f02c402b09c2@gmail.com>
Date: Sun, 3 Jul 2022 23:01:38 +0100
Message-ID: <CAEKnhAEUPn48mOEFPUfYCp23F_PjtwtEjOUY0V2vOwom6rPjwQ@mail.gmail.com>
To: Timon de Groot <tdegroot96@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000021254105e2edc4f8"
Subject: Re: [PHP-DEV] [RFC] Add json_encode indent parameter
From: bukka@php.net (Jakub Zelenka)

--00000000000021254105e2edc4f8
Content-Type: text/plain; charset="UTF-8"

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

--00000000000021254105e2edc4f8--