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
