Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118519 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 21867 invoked from network); 26 Aug 2022 17:53:50 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 26 Aug 2022 17:53:50 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6B97B180084 for ; Fri, 26 Aug 2022 10:53:49 -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=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 26 Aug 2022 10:53:48 -0700 (PDT) Received: by mail-ej1-f48.google.com with SMTP id kk26so4491331ejc.11 for ; Fri, 26 Aug 2022 10:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=ECig2QYG8ji2V9+6cWdIn6J82OIHoJ6MfCJjqxWONDw=; b=i09UQTFflTR9fHsDrSNixYwaFhBr8WMrQfgBJbix4olv5xviiMcSeBeBo+N9MeTPYS Q0SzMrZOjiZ9fVvLIXqXnSEdorF5QGRVG2AeY5ZH1iufpL6/wFKPEylB3AGV+mjWRg8n qmcsl8yAWXdrkIn+Pu3/ujSxjt7C0uSBCGdtKtA/ZJzTAmF/fpc6kfIQW9iE434E+8YL Uq5q6zKD2a2RUrWmyM6yOkKyDvBcoCt51e0RjRql1m38GFliGjlTN8gWsl6vrd1oig17 7Am7NahNvtrMZtbFJIpogkT7/rT2B0DHnsLuUUSqlb6EbIS/pcN2WL3F/Ha+GBjLhmi0 hJ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=ECig2QYG8ji2V9+6cWdIn6J82OIHoJ6MfCJjqxWONDw=; b=KijLCHEoIUcrxB1AjOCiNa+mceQhSDWKJsmJwRZneimQhVBwfIL2wZ2ng9te3/X13K JDrnJ6GEe0FaBgYxSspt2JmeqUeEKKqkqSFtRrOCAMkIjfzz+R3jRp1MOamh2J2xpYHv kRHnD5v0nQgTfCbayo+OfeBX9VLl1skAmlM4/D5MMW1tykxE6CnAN7/M66Fj83PDeMcw +IRN6HmVKhSonqiSy0UR77Qzfju3Odc6dsBhQzbr1DAbZMiu0XJG0sFKi06CEbM3FdTp eBaGqGCCl7o3gZInDNZzTCJ2ngKoqsFe1aqy2DB/rvwbzo9hAgZVMZWUduPv2D1yzcDn nmpQ== X-Gm-Message-State: ACgBeo2brtyW19j0aLO1FkDVw6dQQmybCdYzZ13wnFzFsdXbT6acBY/I rysQFyjzZMtByyTzmHzIFqmBUAnMSS+sF9yIi3x0nvaZ X-Google-Smtp-Source: AA6agR4otKfieFxqKUhwIWM07GU7CAhxVAcX5dquA4G1j6aaPfZk7wCwTkgXiaOHrs+bg3HLuPz/nltBvWLYFjGoZ2k= X-Received: by 2002:a17:907:1611:b0:73d:6d23:5787 with SMTP id hb17-20020a170907161100b0073d6d235787mr6171830ejc.231.1661536427602; Fri, 26 Aug 2022 10:53:47 -0700 (PDT) MIME-Version: 1.0 References: <8D53AD5B-7CFC-4820-9EE4-FEB365D327A8@woofle.net> In-Reply-To: Date: Fri, 26 Aug 2022 18:53:35 +0100 Message-ID: To: Kamil Tekiela Cc: php internals Content-Type: multipart/alternative; boundary="0000000000008c7a7305e7289896" Subject: Re: [PHP-DEV] RFC json_validate() - status: Under Discussion From: davidgebler@gmail.com (David Gebler) --0000000000008c7a7305e7289896 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 26, 2022 at 6:29 PM Kamil Tekiela wrote: > What is the reasoning behind the name? I can't find it explained in the > RFC. What about other alternatives like is_json or validate_json? > The name json_validate makes most sense to me; it groups itself together nicely with the other json_* API functions. I think is_json is what was originally proposed but besides being then inconsistent with the rest of the JSON API function naming, consider most of the is_* functions are for checking types (and some for file properties), not validation. But on the function, the other question which remains for me is whether returning boolean is the right thing to do at all. It seems obviously intuitive it should, returning true for valid and false for invalid JSON but then if you consider you're still going to be in the situation of calling json_last_error() if you want to know why invalid JSON was invalid and in particular you might not expect the "last error" to have changed just from an attempt to check a string. How can there be an error when by definition you weren't trying to do anything except check the validity of some unknown data? Not sure what the answer is there...curious what other people's views are on that. I don't think throwing an exception on invalid JSON is the right answer in any case. --0000000000008c7a7305e7289896--