Everything

php

Moving json extension to core?

php.internals

tyson andre

6 years ago

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.)

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)`

Thanks,
- Tyson

Nikita Popov

6 years ago

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

Aran Reeks

6 years ago

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:

Sara Golemon

6 years ago

On Wed, Apr 29, 2020 at 8:11 AM Nikita Popov <nikita.ppv@gmail.com> 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

Benjamin Morel

6 years ago

>
> Looking at Ubuntu 20.04, they seem to
> have json built-in to the core package anyway. I'm not sure about other
> distros.

Fedora packages it separately as php-json.

I'm a big +1 on moving this extension to core. I've actually asked 2 weeks
ago if it could be disabled
<https://stackoverflow.com/questions/61230326/can-ext-json-be-disabled>,
because I want my classes to implement JsonSerializable, but this means
requiring ext-json and bumping the library version.

- Ben

Sara Golemon

6 years ago

On Wed, Apr 29, 2020 at 5:36 PM Benjamin Morel <benjamin.morel@gmail.com>
wrote:

> I want my classes to implement JsonSerializable, but this means requiring
>> ext-json and bumping the library version.
>>
>
> At the risk of derailing... You can have your class implement the

interface unconditionally, then have a polyfill definition in your autoload
for cases where it doesn't exist.  Obviously, it won't have an impact on
calls to json_encode(), but if the interface doesn't exist it's because
json_encode() doesn't either, so that should be harmless. :D

-Sara