Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:118314 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 59770 invoked from network); 29 Jul 2022 18:56:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Jul 2022 18:56:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E0F35180384 for ; Fri, 29 Jul 2022 13:55:35 -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-yb1-f196.google.com (mail-yb1-f196.google.com [209.85.219.196]) (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, 29 Jul 2022 13:55:35 -0700 (PDT) Received: by mail-yb1-f196.google.com with SMTP id 204so9002654yba.1 for ; Fri, 29 Jul 2022 13:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VqmbmPIJTSMfumDHpCvm2fVOA0BloSPKY2lPbBOqUog=; b=VAd+trvdG1MyrXRdoEnn5Jzf8DTLf3o/cTqV781Js8SHu1QBGNa+sSxB7KoBubIBFo Gj53q+ucVzRj2FPlrk8woZgMgMfU9no9tNsn0MOWUanAoR/woq+wzZ388MwIr0cOmp35 8kDFV9Y4S+mtJwUj9aSvhoK50em9mja94yIgXpOyS3cEiqalYOCRR+nd7oylgF5TNU38 UgUAbXhTt2Goyfgne2V0wNXLO7jL/IDfDlZByn09cVEXK8gm4V5OxGueDcTClYR4tWAy CftA6h4Ob+KgNUNp4UJLrybYHA5Unr7DN6vQNlOS4wvCyO//pG1Aa0M/lnjnS8a/5tWx W+dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VqmbmPIJTSMfumDHpCvm2fVOA0BloSPKY2lPbBOqUog=; b=nTiBTgWOYXQRFpH8sufXgirujra/gijv8gWGyZFZcAvh9P7qD9M+TYPSHbKs2cZaTL PPKofpSgrAJx8keQc4qO5aqLvDz2DSYRm1h1iTePVADirn1NZWmT41zbjq1rz4XGFkZg v6CE2hPD6R9MlDJvf/z7/GpxY2KEo/rP1i63oPKZF4mV8lVAZpqbbWNOt0oicFe0EQvf utql/TjAOkImACkqxmRkIXSUk1Z5B48Dy5F82PoyjiM9a4VpiEzkR6KS49SxhdkXln+t 5q7ttfX1V6Zz+eB3+xm+TRrFiK978NNuXA/9M29INQYwRHDzHXlXiBGcIwp0ECG0X+lW ansA== X-Gm-Message-State: ACgBeo39FlBpwCsHoKp0RGXm3nC/72x7kAhvMPA1PsdWZ/o3yvJlA0XH Wc8fBpoMsbPtdCmrXncit6IeBiW4A0Jh4dm743Q= X-Google-Smtp-Source: AA6agR7cpiUm9aZ2zl3QfKxOt8Rx3/3RwVesKDc8ACE8v7XvoD0PAx/JgW4M10rsFAvqp81T2akyF9WjtYMiGdA8Nxg= X-Received: by 2002:a25:b9d1:0:b0:671:49f9:4e01 with SMTP id y17-20020a25b9d1000000b0067149f94e01mr4195687ybj.398.1659128134799; Fri, 29 Jul 2022 13:55:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 29 Jul 2022 22:55:24 +0200 Message-ID: To: David Rodrigues Cc: PHP Internals List Content-Type: multipart/alternative; boundary="0000000000001c94d905e4f7dfe3" Subject: Re: [PHP-DEV] RFC Idea - is_json - looking for feedback From: dev.juan.morales@gmail.com (juan carlos morales) --0000000000001c94d905e4f7dfe3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El vie, 29 jul 2022 a las 22:18, David Rodrigues () escribi=C3=B3: > I was about to say NO, but after being completely your argument, the idea > makes sense. > > Initially I thought about using json_decode() with error capture, but the > idea that it would overload memory makes perfect sense, compared to a > simple structure analysis, if that is indeed the user's intention. The > performance would also be absurdly better. > > What worries me above is the misuse of the function, like checking if > is_json() =3D=3D=3D true and using json_decode() right after. However, I = believe > this can be easily optimized by the engine itself. > > My vote is YES. > > > Atenciosamente, > David Rodrigues > > > Em sex., 29 de jul. de 2022 =C3=A0s 16:32, Micha=C5=82 Marcin Brzuchalski= < > michal.brzuchalski@gmail.com> escreveu: > > > Hi Juan, > > > > pt., 29 lip 2022, 16:26 u=C5=BCytkownik juan carlos morales < > > dev.juan.morales@gmail.com> napisa=C5=82: > > > > > I am following the RFC guideline for the first time. ( > > > https://wiki.php.net/rfc/howto) > > > > > > As suggested there, I am here to get a feeling from you, regarding th= e > > > following RFC for PHP. > > > > > > # Change (draft): > > > > > > New function in php called like: > > > > > > is_json(string $string): bool > > > > > > ## Description > > > ### Parameters > > > string $string -> string to find out if is a valid JSON or not > > > > > > ### Return > > > Returns a bool. The function is capable to determine if the passed > string > > > is a valid JSON (true) or not (false). > > > > > > # Why this function ? > > > > > > At the moment the only way to determine if a JSON-string is valid we > have > > > to execute the json_decode() function. > > > > > > The drawback about this, is that json_decode() generates an in memory > an > > > object/array (depending on parameters) while parsing the string; this > > leads > > > to a memory usage that is not needed (because we use memory for > creating > > > the object/array) and also can cause an error for reaching the > > memory-limit > > > of the php process. > > > > > > > Personally I'd vote NO. > > > > Cheers, > > Micha=C5=82 Marcin Brzuchalski > > > > > > > > Thanks for the feedback *** To: Micha=C5=82 Marcin Brzuchalski Thanks for the opinion, but it would be useful for me to know if there is a reason behind the "no" that could help me get better. *** To: David Rodrigues Gracias. Regarding "performance", I did some benchmarks. I tested is_json() vs json_decode() with a json-string with 1 million key-values; is_json was 100% faster than json_decode(), plus memory usage with is_json() was flat! , yes , flat. memory_get_usage() before and after is_json() returned the same value; with json_decode() I had to change the memory limit setting otherwise memory reaches max allowed before finishing parsing it. Regarding use cases, I can say that this idea came up , as in my current company , our product heavily uses json_decode() to know if an string is a valid json, and compromises the memory usage once in a while, plus, performance decreases; that is why this RFC-Idea. The good thing is that I already have something for this. Also in stack overflow, honestly, take a look, and check how much people is needing this. Unit tests could heavily benefit from such a functionality. A quick look in github for php code with a function called "is_json()" exposes tons of projects where developers are writting their own "is_json()" function relaying in json_decode() to make it work. Etc. :) Stay in contact David. and once again, thanks! --0000000000001c94d905e4f7dfe3--