[RFC] Always available JSON extension

From: Date: Thu, 30 Apr 2020 00:20:56 +0000
Subject: [RFC] Always available JSON extension
Groups: php.internals 
Request: Send a blank email to internals+get-109939@lists.php.net to get a copy of this message
Hi internals, I've created https://wiki.php.net/rfc/always_enable_json with an implementation at https://github.com/php/php-src/pull/5495 The proposal is to make it impossible to disable the JSON extension through configuration or build options, and require that JSON be built statically instead of as a shared library (to avoid linker errors or extension=json being commented out). > Currently, it's possible to disable the json extension with ./configure > –disable-json. > However, JSON is extremely useful to have because it's widely used for many use cases > (web sites, logging output, and as a data format that can be used to share data with > many applications and programming languages), > so it would be useful for PHP maintainers and users to guarantee that json is always enabled. Responses to earlier questions in my earlier thread "Moving json extension to core?" in https://externals.io/message/109783 > 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. Agreed - limiting this to making JSON a "core" builtin (similar to "hash" in 7.4) was my intent. The printf comment was to measure interest in a potential followup RFC that would depend on this (and give an example of internal functionality this would allow.). > 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 That would work for userland, but might cause problems if multiple PECL modules were to take that approach, because they'd define duplicate classes. Thanks, - Tyson

« previous php.internals (#109939) next »