Req #68288 [Opn->Sus]: Closure should implement JsonSerializable
| From: | stas@php.net | Date: | Sat, 05 Aug 2017 04:54:42 +0000 |
| Subject: | Req #68288 [Opn->Sus]: Closure should implement JsonSerializable | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-210518@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=68288&edit=1
ID: 68288
Updated by: stas@php.net
Reported by: dmitry dot soshnikov at gmail dot com
Summary: Closure should implement JsonSerializable
-Status: Open
+Status: Suspended
Type: Feature/Change Request
Package: Scripting Engine problem
Operating System: CentOS 6
PHP Version: 5.5Git-2014-10-22 (Git)
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2014-12-18 18:51:25] 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.
------------------------------------------------------------------------
[2014-12-18 18:24:24] 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-10-22 23:30:29] 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,{}]"
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=68288&edit=1