[PHP-DEV] [RFC][Vote] Add json_encode indent parameter

2022-07-04 Thread Timon de Groot

Hi internals,

I went with Jakub's advice and opened the vote, not getting into any 
other adjustments to the RFC prior to opening it for vote.


The vote for the json_encode 'indent' parameter is now open. It will run 
until 15 July.


RFC: https://wiki.php.net/rfc/json_encode_indentation.

Kind regards,

Timon

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



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

2022-07-04 Thread Timon de Groot
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 





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



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

2022-07-04 Thread Timon de Groot

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!


Kind regards,

Timon

On 04-07-2022 00:01, Jakub Zelenka wrote:

Hi,

On Fri, May 13, 2022 at 2:33 PM Timon de Groot <mailto:tdegroo...@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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



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

2022-05-13 Thread Timon de Groot

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!


--

Kind regards,
Timon

[1] https://datatracker.ietf.org/doc/html/rfc4627
[2] https://github.com/php/php-src/pull/7093
[3] https://wiki.php.net/rfc/json_encode_indentation

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



[PHP-DEV] [RFC][Draft] Add json_encode indent parameter

2021-06-03 Thread Timon de Groot

Hi internals,

I'd like to present my RFC for adding the indent parameter to the 
json_encode function:

  https://wiki.php.net/rfc/json_encode_indentation

The `string|int $indent = 4` parameter adds the ability to specify the 
indentation for
the JSON encoder. Amount of spaces can be specified by a number and a 
string can be

specified to set a custom indentation like `\t` or whatever.

As this is my first RFC (and contribution) for PHP, I'm all kind of new 
to the process, standards, etc.

Please let me know if I could do something better.

Looking forward to feedback/input on the RFC.

--

Kind regards,

Timon de Groot

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] json_encode indent parameter

2021-06-03 Thread Timon de Groot

On 3-6-2021 17:53, Ayesh Karunaratne wrote:

Hi Timon,
Thank you for this RFC. I think the `string|int $indent` approach is great !

Reading the PR, it looks like `$indent=0` is essentially turning off
pretty-print, which I think is intuitive.
Basically, yes. With `$indent=0`, no indentation will take place but new 
lines will still be added.

Do you plan to add any sort of validation on negative integers?
Perhaps throw a `\ValueError` exception on $indent < 0?


Good question. Personally I'd prefer clamping $indent to 0 when it 
reaches below 0. But I'd like

to hear about what other particpants think about such behavior.

Thank you for your feedback :).

--

Kind regards,

Timon de Groot

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] json_encode indent parameter

2021-06-03 Thread Timon de Groot

On 3-6-2021 16:15, G. P. B. wrote:

That's incorrect, as of PHP 8.0 Fast ZPP has a way to deal with the most
common union types, including int|string.

Best regards,

George P. Banyard


I found that STR_OR_LONG works fine, thanks for acknowledging!

--

Kind regards,

Timon de Groot

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



[PHP-DEV] RFC karma for tdgroot

2021-06-03 Thread Timon de Groot
I'm requesting RFC karma for my proposal in discussion '[PHP-DEV] 
json_encode indent parameter'.


For those interested in my public profile, please see my Github profile: 
https://github.com/tdgroot.


If you have any questions, please let me know!

--

Kind regads,

Timon de Groot

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] json_encode indent parameter

2021-06-03 Thread Timon de Groot

On 3-6-2021 10:00, Jordi Boggiano wrote:
I agree, but I'd make it accept a string|int much like JSON.stringify 
does, because that way you let people pass in tabs too, or "" if 
that's how you want your JSON indented..


I like the idea of accepting string|int.

Accepting string|int means a zval needs to be used, with the possibility 
to pass any type of variable (please correct me if I'm wrong here).
Should the function throw an error when it receives anything other than 
a string|int?


--

Kind regards,

Timon de Groot

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] json_encode indent parameter

2021-06-03 Thread Timon de Groot



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.


Thank your for your input, I'll start working on an RFC to introduce a 
new parameter for json_encode.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



[PHP-DEV] json_encode indent parameter

2021-06-02 Thread Timon de Groot
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?
2. How would that parameter work when the JSON_PRETTY_PRINT option is 
not passed?

3. What do you think of adding json_encode options instead, like
  JSON_PRETTY_PRINT_INDENT_2 and JSON_PRETTY_PRINT_INDENT_4?

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