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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
