Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114702
MIME-Version: 1.0
References: <e1942470-dc68-0e20-3ccd-da420da74cb9@gmail.com>
In-Reply-To: <e1942470-dc68-0e20-3ccd-da420da74cb9@gmail.com>
Date: Thu, 3 Jun 2021 01:45:47 +0100
Message-ID: <CA+p1FabKpJq=PKSag1-cJQfQ5VTms2Mu=mshD5Tu52Km1-CErQ@mail.gmail.com>
To: Timon de Groot <tdegroot96@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ea01fe05c3d1e568"
Subject: Re: [PHP-DEV] json_encode indent parameter
From: davidgebler@gmail.com (David Gebler)

--000000000000ea01fe05c3d1e568
Content-Type: text/plain; charset="UTF-8"

On Wed, 2 Jun 2021, 23:03 Timon de Groot, <tdegroot96@gmail.com> wrote:

> It's not possible to tell json_encode what indentation level should be
> used when using
> the JSON_PRETTY_PRINT option (2, 4, 8, etc). When generating JSON files
> which can be
> used/read/edited by users, indentation starts to become a relevant topic.
>
> - JavaScript has a function called JSON.stringify wich accepts the
> optional 'space' parameter
>    - See
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
>
> - Python has a function called json.dump which accepts the optional
> 'indent' parameter
>    (which also controls pretty printing)
>    - See https://docs.python.org/3/library/json.html#basic-usage
>
> I would like to create an RFC draft to implement an 'indent' parameter.
> Before I start a draft, I need to know if this is a good idea, so I
> start with a few questions.
>
> 1. What do you think of adding an 'indent' parameter?
>

I'm not at all opposed in principle. As you've pointed out, there is both a
use case and precedent in other common languages.

2. How would that parameter work when the JSON_PRETTY_PRINT option is
> not passed?
>

Give it a default value equivalent to whatever JSON_PRETTY_PRINT spits out
at the moment and silently ignore it if not formatting?

3. What do you think of adding json_encode options instead, like
>        JSON_PRETTY_PRINT_INDENT_2 and JSON_PRETTY_PRINT_INDENT_4?
>

Personally I'd avoid more magic constants. The argument in favour of this
approach I suppose would be a) there are in practice a very small number of
common values for indentation which tend to be used, 2 and 4 being the most
common and b) there is already a third, optional depth parameter which
would remain before any fourth spacing parameter.

I would say though (a) is true enough but doesn't necessarily cover all use
cases, adds more magic constants and doesn't provide equivalence to the
JSON libraries of other common languages which permit for custom values,
while (b) is less of an issue with PHP 8's named parameters.

So if you do go ahead and make an RFC for this, I think my preference would
be as a new parameter on json_encode accepting a positive integer.


> Looking forward to you replies and feedback!
>
> --
>
> Kind regards,
>
> Timon de Groot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--000000000000ea01fe05c3d1e568--