php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #68288 Closure should implement JsonSerializable
Submitted: 2014-10-22 23:30 UTC Modified: 2017-08-05 04:54 UTC
Votes:3
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
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
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 
Description:
------------
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 "{}".

Example:

// 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: https://github.com/facebook/hhvm/issues/4035), 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 "{}"?

Dmitry

Test script:
---------------
<?php

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

Expected result:
----------------
"[1,2,3,null]"

Actual result:
--------------
"[1,2,3,{}]"

Patches

Pull Requests

History

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] aharvey@php.net
-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] aharvey@php.net 
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] stas@php.net
-Status: Open +Status: Suspended
 [2017-08-05 04:54 UTC] stas@php.net 
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 (internals@lists.php.net) as an RFC. Please read the guide about creating RFCs here:
https://wiki.php.net/rfc/howto
If you haven't had experience with writing RFCs before, it is advised to seek guidance on the Internals list (http://php.net/mailing-lists.php) 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-2025 The PHP Group
All rights reserved. 		Last updated: Tue Oct 28 15:00:02 2025 UTC