Moving json extension to core?

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, 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

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