Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109921
MIME-Version: 1.0
References: <DM6PR07MB661888F247EBFB154788CE8CF9D20@DM6PR07MB6618.namprd07.prod.outlook.com>
 <CAF+90c_siC7495c-D3D1kpJJo12Aqpdirw1u-6NfjhC_t3JaAg@mail.gmail.com>
In-Reply-To: <CAF+90c_siC7495c-D3D1kpJJo12Aqpdirw1u-6NfjhC_t3JaAg@mail.gmail.com>
Date: Wed, 29 Apr 2020 14:29:00 +0100
Message-ID: <CAKtGGAvysUHMWzOKkn8TJEYDTkG0pMdgndD+9kWXsBw7ojhdig@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: tyson andre <tysonandre775@hotmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000094b2c05a46def10"
Subject: Re: [PHP-DEV] Moving json extension to core?
From: cdtreeks@gmail.com (Aran Reeks)

--000000000000094b2c05a46def10
Content-Type: text/plain; charset="UTF-8"

I've no objections to JSON becoming part of PHP's core, it's so commonplace
these days I'd welcome it.

If JSON were to become a part of core, what would people think about
introducing support for a streaming JSON parser?

Having worked with many integrations where you simply get shipped a large
block of JSON, we've frequently encountered issues decoding that with
json_decode() due to memory limits being exceeded when bringing it all into
memory at the same time.

I'm not completely certain how easily achievable this could be, but welcome
thoughts from others.

Regards,
Aran

On Wed, 29 Apr 2020 at 14:11, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Wed, Apr 22, 2020 at 7:38 PM tyson andre <tysonandre775@hotmail.com>
> wrote:
>
> > Hi internals,
> >
> > Currently, it's possible to disable the json extension with `./configure
> > --disable-json`.
> > However, JSON is widely used in many use cases - web sites, logging
> > output, and as a data format that can be used in CLI programs
> > to share data with many applications and programming languages, so I'd
> > personally find it useful if it was always enabled.
> > (e.g. to publish self-contained scripts that don't require polyfills or
> > less readable var_export output)
> >
> > https://wiki.php.net/rfc/jsond mentions that
> >
> > > The current Json Parser in the json extension does not have a free
> > license which is a problem for many Linux distros.
> > > This has been referenced at Bug #63520. That results in not packaging
> > json extension in the many Linux distributions.
> >
> > Starting in php 7.0, I'd assume licensing is no longer an issue (correct
> > me if I'm wrong). I don't see anything discussed in the RFC or a quick
> > search of email threads about making JSON impossible to disable.
> >
> > 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.
>
> So tentatively, I'm +1 on making ext/json a required extension.
>
>
> > 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.
>
> Regards,
> Nikita
>

--000000000000094b2c05a46def10--