|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #68288 Closure should implement JsonSerializable
Submitted: 2014-10-22 23:30 UTC Modified: 2017-08-05 04:54 UTC
Avg. Score:3.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: dmitry dot soshnikov at gmail dot com Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: 5.5Git-2014-10-22 (Git) OS: CentOS 6
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: dmitry dot soshnikov at gmail dot com
New email:
PHP Version: OS:


 [2014-10-22 23:30 UTC] dmitry dot soshnikov at gmail dot com
The `json_encode` in PHP 5.5.17 encodes a closure object as "{}". By analyzing the code, I found out that it might be a bug, since json encoder doesn't have any special treatment of closure objects, and just fallback to the array-encoder, which eventually outputs the "{}".


// PHP
json_encode([1,2,3, function () {}]); // "[1,2,3,{}]"

In HHVM team we'd like to conform the behavior (the discussion is in this issue thread:, however, think that encoding a closure as "{}" doesn't make big sense, since it cannot be decoded back as a closure.

For the record, e.g. ECMAScript encodes all non-JSON values as undefined (or null in arrays):

// ECMAScript
JSON.stringify([1,2,3, function () {}]) // "[1,2,3,null]"

My question are:

1. Is it actual PHP bug?
2. If yes, will it make sense to encode closure objects as `null` instead of "{}"?


Test script:

json_encode([1,2,3, function () {}]); // "[1,2,3,{}]"

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-12-18 18:24 UTC] dthomas at starkartthenala dot com
FWIW, I'm experiencing this with Ubuntu 14.04, PHP 5.5.9-1ubuntu4.5 (cli) (built: Oct 29 2014 11:59:10)
 [2014-12-18 18:51 UTC]
-Summary: Encoding a clsoure as "{}" in json_encode +Summary: Closure should implement JsonSerializable -Type: Bug +Type: Feature/Change Request -Package: JSON related +Package: Scripting Engine problem
 [2014-12-18 18:51 UTC]
I don't think we'd want to special case this in the JSON encoder — there are more internal classes than just Closure that don't have useful public properties and would have this issue, and having a blacklist of classes that we treat differently seems like it'll cause problems down the track.

What we could do instead would be to have Closure objects implement JsonSerializable and return NULL (or some other appropriate value) from jsonSerialize(). I'm not sure there's a tonne of value in making that change, but let's kick this over to the scripting engine category and see if other people have opinions.
 [2017-08-05 04:54 UTC]
-Status: Open +Status: Suspended
 [2017-08-05 04:54 UTC]
Thank you for your interest in PHP and for submitting a feature request. Please be aware that due to the magnitude of change this request requires, it would be necessary to discuss it on PHP Internals list ( as an RFC. Please read the guide about creating RFCs here:
If you haven't had experience with writing RFCs before, it is advised to seek guidance on the Internals list ( and/or solicit help from one of the experienced developers. 

Please to not consider this comment as a negative view on the merits of your proposal - every proposal which requires changes of certain magnitude, even the very successful and widely supported ones, must be done through the RFC process. This helps make the process predictable, transparent and accessible to all developers.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Sep 22 15:01:23 2020 UTC