Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109933 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62287 invoked from network); 29 Apr 2020 20:38:40 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Apr 2020 20:38:40 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 042F11804C2 for ; Wed, 29 Apr 2020 12:12:08 -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=1.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_SOFTFAIL 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-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (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 ; Wed, 29 Apr 2020 12:12:07 -0700 (PDT) Received: by mail-qt1-f172.google.com with SMTP id o10so2877405qtr.6 for ; Wed, 29 Apr 2020 12:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UF0/+V9to8vxT/znGNc6AzlYcRIQ2EX3wrR4M3z97Gk=; b=rH+i5ZMIxs5YIItJ9E+eVFjFODWFeoNAkDzQdPKd+nupcuEFgXm81qYuFcj21I6OOU xqnYwcJUeZcw23mV/uiwbc2r8hCS93fSWw5ytzIAK6rH/ICqN8gZAjagjnH3LHz8ewcA NPbE9RIl5oNZd5OpEyLss8mpPnTHcJlL8IoJwFABi+8+ddo1+18WpocB16Y/t1Jty/RR TGaB5g/B0slYbqaOD5KDGZtuGoY03DER1Ldz5oyH/+YTXgTtnYEYHm/4jz7u177PpqmB K/eE9O0E//yx5URwyndw3BDY/e/vzaK37M1E1QuQ/OKNW+Spv0yX8ZYk+XCPszz0D3lG s8wA== X-Gm-Message-State: AGi0PuY+LQumh2UVbo1Yd9o28/nzbt+lzZm/9kF5RqBQBYhX2CTRsGUZ JP1uzFWxZKT6kW3sYSUONx9QxUjeLJz4HjqRfUxB4g== X-Google-Smtp-Source: APiQypLSCZgxVHREuEP0TFbCfi2XLr2F8xTZw9NymglRMizMdMI/eHUEbPEAWPaOOwAs8AMGgzLFRqTswAAH7zD8ETQ= X-Received: by 2002:ac8:4983:: with SMTP id f3mr35541319qtq.343.1588187526562; Wed, 29 Apr 2020 12:12:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 29 Apr 2020 14:11:55 -0500 Message-ID: To: Nikita Popov Cc: tyson andre , Internals Content-Type: multipart/alternative; boundary="0000000000005b98a405a472b9ea" Subject: Re: [PHP-DEV] Moving json extension to core? From: pollita@php.net (Sara Golemon) --0000000000005b98a405a472b9ea Content-Type: text/plain; charset="UTF-8" On Wed, Apr 29, 2020 at 8:11 AM Nikita Popov wrote: > > Doing this would also make some extensions more convenient to use (e.g. > > memcached with the json serializer, using json encoding for uses such as > > error messages in miscellaneous extensions, etc.) > > > > Another advantage would be that the JsonSerializable interface would be > always available. This would make things simpler for extensions that want > to hook into that. Currently we have a bunch of classes like DateTime, > which do have custom JSON serialization behavior, but do not implement > JsonSerializable, because the class is not always available. > > Technically, we could have these classes always implement the method and only attach the interface conditionally during MINIT, but for sure the mechanics become both simpler and more reliable for userspace scripts. This gets a pretty easy +1 from me. Looking at Ubuntu 20.04, they seem to have json built-in to the core package anyway. I'm not sure about other distros. > > P.S. What are your thoughts about adding additional conversion specifiers > > such as %j or %v to PHP to call JSON with the default options. > > It's a feature similar to those I've seen in programming languages such > as > > golang - https://golang.org/pkg/fmt/#hdr-Printing > > > > - `printf("console.log("value from php", %j);\n", $value)` > > - `printf("Some command returned %j\n", $boolValue)` > > > > Uh, dunno. Is it really common to want JSON inside printf? I see printf > mostly as something used to output to console, not so much in a web / data > interchange context. > > It's possible (with some elbow-grease to make the %j approach a bit more efficient since one could stream the serializer straight to the output, but if that's really desired, there are other more explicit ways to make it happen. Ignoring streaming efficiency, the only real gain is replacing `"%s", json_encode($x)` with `"%j", $x` which is of questionable gain. In terms of getting it passed, I'd focus on just the first part, making JSON a "core" builtin. Let the printf modifier be a separate RFC, or at least a separate question. -Sara --0000000000005b98a405a472b9ea--