Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:117726 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 79024 invoked from network); 13 May 2022 11:53:54 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 May 2022 11:53:54 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 13BC7180382 for ; Fri, 13 May 2022 06:33:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 13 May 2022 06:33:20 -0700 (PDT) Received: by mail-ej1-f46.google.com with SMTP id bv19so16303965ejb.6 for ; Fri, 13 May 2022 06:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=nullWXjN426d/To35+f/HaAzrWSJM8TKTRLFBThiTNA=; b=m65lb5qucP0c9D/6IwFX1lHLiYVsNpTZE5oJ4xcy6oQcglWQ2Nis/gDL5w1q8BCIXA ZA1ZS359AMcMHreNCZCAt2bLz6Y75lxxWZWDyYqbh1e9P0jlzd+v4vqAHy4PsvpZRhlO bWVkz7uBAWSwfjShrP1evXmxmao4QND7Asm486Z0QuYuqfOZOJylS7vR2mn2HWHiegxK onnvA7ts9/tOzlzMwB3Q2UX5PpR1lJyMoxzHigrFLBWH5xrstmcVZNcMSBqu/wfcsGqL Cxd8i2ouCHW9eiV6wL9ytNxvN59f6FZ9xXhQatM6WCTmcr+/nbsaT4JMsksngv3L0v/P h+Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=nullWXjN426d/To35+f/HaAzrWSJM8TKTRLFBThiTNA=; b=FeZQAfyBvoszEEpopRFtzxK7dyUUOPbro4O6ML99j7G202MWS8qY9mOUc4jpRQHEO0 Z7tVwow/xm2G8/a9zakyvbdvHFiAfODvQvfd/pvzHNvKhoncyCZhM/WNPiZ7g9ak8K9W RGBwAZOTQ2pS1vyC5I/9oBMJwoFR15ZVj3v/kG8LjDXSTkmOP4QfYcCjs30woldUYLcy rL2j9Lb0SepUgRVk6UwZownISziON4D4LfoQoVZ3jgpHlUb4dXTXoeO7tWbK/dhay3zd dEUF7w8PqWtE3i5Dd0vfhKM9zooV0MdDrxMILGJxWs65HqlS9Vx82nLJ6khocjeappOU XLcw== X-Gm-Message-State: AOAM5335G9/uUMFMbWjyHOa+p2F9DI8QidQJKIKJPVFQfYgksgWMgn4K DBw2vjTdqw+RfWB7bkmqY6zDGITdU2HDng== X-Google-Smtp-Source: ABdhPJycKKwi1Io7ofsz7wJ0ocFi/p6OwkC9xmFsX/tdwvv0xfg90FR8Ea2wwXAwrNjr7Znm8h+BPw== X-Received: by 2002:a17:907:3d89:b0:6f4:7e66:b500 with SMTP id he9-20020a1709073d8900b006f47e66b500mr4269379ejc.134.1652448799276; Fri, 13 May 2022 06:33:19 -0700 (PDT) Received: from ?IPV6:2a01:7c8:7c8:f866:10::1002? ([2a01:7c8:7c8:f866:10::1002]) by smtp.gmail.com with ESMTPSA id t19-20020aa7db13000000b0042617ba63a4sm958693eds.46.2022.05.13.06.33.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 May 2022 06:33:18 -0700 (PDT) Message-ID: <7d72b5c1-d19b-8734-57e0-f02c402b09c2@gmail.com> Date: Fri, 13 May 2022 15:33:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: PHP internals Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [RFC] Add json_encode indent parameter From: tdegroot96@gmail.com (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