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....@gmail.com> wrote: > On Wed, Apr 22, 2020 at 7:38 PM tyson andre <tysonandre...@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 >
