Re: [RFC] Add json_encode indent parameter

On 05.07.22 11:38, Jakub Zelenka wrote:

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

Hey all. On 05.07.22 02:04, Peter Cowburn wrote:

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

On Mon, Jul 4, 2022 at 8:38 AM Timon de Groot <tdegroot96@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.

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

Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0xA8D5437ECE724FE5.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc