Re: [RFC] Add json_encode indent parameter

As a flag can't really hurt, I'm thinking of going with option B before starting the vote. Also agree with ignoring the indent parameter, as a tab character is less dependent on how much it is repeated. Kind regards, Timon On 04-07-2022 03:22, Kevin Israel wrote:

On 7/3/22 18:01, Jakub Zelenka wrote:

  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

This RFC really should have included an option to use tabs instead of spaces, which is, IMO, even more important than having a parameter for the number of spaces. This could take the form of either (a) a magic indent value such as -1, or (b) a new flag (suggested name: JSON_INDENT_USING_TABS). There should be no need to support indenting using multiple tabs per level; for option (b), the value of the indent parameter should be ignored. An indent-using-tabs flag would even be useful for generating two-space indented JSON, should the proposed indent parameter be rejected. The reason is that tabs cannot occur within JSON string representations, so any other indent string is a simple str_replace() away. In contrast, replacing the current four-space indent with anything else is more complicated to do efficiently[1]. [1]: https://github.com/wikimedia/mediawiki/blob/210a34369ac8f0ba74b497d0b2298ca7e5a0bffb/includes/json/FormatJson.php#L113-L117