Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109939
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [RFC] Always available JSON extension
Thread-Index: AQHWHoMfwYl/VPysCU+BThJopcVmdQ==
Date: Thu, 30 Apr 2020 00:20:56 +0000
Message-ID:
 <DM6PR07MB661824E60665E8C37329454CF9AA0@DM6PR07MB6618.namprd07.prod.outlook.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 057caa30-a01e-448d-6013-08d7ec9c5a07
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 00:20:56.5200
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT215
Subject: [RFC] Always available JSON extension
From: tysonandre775@hotmail.com (tyson andre)

Hi internals,=0A=
=0A=
I've created https://wiki.php.net/rfc/always_enable_json with an implementa=
tion at https://github.com/php/php-src/pull/5495=0A=
=0A=
The proposal is to make it impossible to disable the JSON extension through=
 configuration or build options,=0A=
and require that JSON be built statically instead of as a shared library=0A=
(to avoid linker errors or extension=3Djson being commented out).=0A=
=0A=
> Currently, it's possible to disable the json extension with `./configure =
=96disable-json`.=0A=
> However, JSON is extremely useful to have because it's widely used for ma=
ny use cases=0A=
> (web sites, logging output, and as a data format that can be used to shar=
e data with =0A=
> many applications and programming languages),=0A=
> so it would be useful for PHP maintainers and users to guarantee that jso=
n is always enabled.=0A=
=0A=
Responses to earlier questions in my earlier thread "Moving json extension =
to core?" in https://externals.io/message/109783=0A=
=0A=
> In terms of getting it passed, I'd focus on just the first part, making=
=0A=
> JSON a "core" builtin. Let the printf modifier be a separate RFC, or at=
=0A=
> least a separate question.=0A=
=0A=
Agreed - limiting this to making JSON a "core" builtin (similar to "hash" i=
n 7.4) was my intent.=0A=
The printf comment was to measure interest in a potential followup RFC that=
 would depend on this=0A=
(and give an example of internal functionality this would allow.).=0A=
=0A=
> At the risk of derailing... You can have your class implement the=0A=
> interface unconditionally, then have a polyfill definition in your autolo=
ad=0A=
> for cases where it doesn't exist. Obviously, it won't have an impact on=
=0A=
> calls to json_encode(), but if the interface doesn't exist it's because=
=0A=
> json_encode() doesn't either, so that should be harmless. :D=0A=
=0A=
That would work for userland, but might cause problems if multiple PECL mod=
ules were to take that approach,=0A=
because they'd define duplicate classes. =0A=
=0A=
Thanks,=0A=
- Tyson=0A=