Req #68288 [Opn->Sus]: Closure should implement JsonSerializable

From: 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

« previous php.bugs (#210518) next »