Re: [PHP-DEV] [RFC] Add json_encode indent parameter

[Andreas Heigl]

On 05.07.22 11:38, Jakub Zelenka wrote:

On Tue, Jul 5, 2022 at 8:37 AM Andreas Heigl <andr...@heigl.org> wrote:

Hey all.

On 05.07.22 02:04, Peter Cowburn wrote:

On Mon, 4 Jul 2022 at 11:11, Jakub Zelenka <bu...@php.net> wrote:

On Mon, Jul 4, 2022 at 8:38 AM Timon de Groot <tdegroo...@gmail.com>
wrote:

Hi internals,

If the rest also thinks the RFC is good to go, I suggest we start a

vote

coming week.
As this is my first RFC, I'm not so sure how this typically gets kicked
off, so I'd like to know what I need to do!

You just need to change status in RFC to Voting and in voting section

set

the date range and add doodle poll - you can basically copy it from one

of

the open RFC's (see for example code in
https://wiki.php.net/rfc/fetch_property_in_const_expressions ). Then

you

just need to send email to internals with subject prefixed with

[RFC][VOTE]

or similar. As noted you need to do it today or latest tomorrow. Feel

free

to let me know if you are too busy or something is not clear.

I would recommend not to do any last time changes as in such case you
should probably give an extra time for dicusion which means it won't

make

the feature freeze and will have to wait for another year. In my

opinion it

is good as it is. The tabs can be later added as an extra flag. If the

flag

is set, we could just change default value for indent to 1 and use tabs

but

it would be still possible for users to set indent size if they wish. I
think that's something that makes most sense to me and doesn't impact

the

current RFC in any way.

Regards

Jakub

My thoughts might be firmly in the realms of "too little, too late" since
the vote is open already, so by all means choose to ignore.

I'll be on the same lines!

What I would have prefered is instead of a the new parameter $indent
having a numerical value to have a string value.

That would have allowed the following:

      json_encode($data, indent: "    ");

or

      json_encode($data, indent: "\t");

That would have made the tabs vs. spaces very easy and people can also
add whatever they want to set for one indentation. Think about setting
dots for making the spaces visible for some formatted output or whatever
else people might think of.

The problem with this approach is that we either need to validate it (which
is probably not a big deal but you still have just option or using spaces
or tabs) or we allow invalid JSON to be produced from this function which I
think it's not a good idea and should not be part of json_encode because,
as its name suggests, that function is just for encoding JSON and not some
random format. My guess is that it would be even less likely to pass and I
would certainly vote against it.

I think if this RFC fails, we could maybe allow number or validated string
and also do that auto setting of flag if set as suggested.

Cheers

Andreas

--
                                                              ,,,
                                                             (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andr...@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+

Then perhaps adding a separate function "json_format" would be the better approach? Keep `json_encode` to *only* encode json into a "binary" format (and then it's irrelevant whether that's spaces or tabs) and explicitly use a different function to handle possible formatting topics with different spaces, tabs whatever-else-one-might-find-adequate....

OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature