Re: svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.hext/json/tests/serialize.phpt
| From: | Sara Golemon | Date: | Wed, 12 May 2010 08:29:19 +0000 |
| Subject: | Re: svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.hext/json/tests/serialize.phpt | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48265@lists.php.net to get a copy of this message | ||
Stanislav Malyshev wrote:
One is meant for freezing and restoring a given object with preservation of state and type while the other is not (i.e. unserialize() returns to a specific object type via __wake() while json_decode() simply becomes a stdClass object). serialize() stores objects in files and apc caches and *perhaps* is used for trading between PHP instances via IPC. JSON serializes data for use by Javascript on web pages. Very different use-cases. I suppose serialize() could be dual purposed, but that requires using debug_backtrace() in an awfully wasteful way IMO. -SaraAdd JSON_Serializable interface Objects implementing JSON_Serializable will have their ->jsonSerialize() method called Similar to serialize() and __sleep()Why should we have special mechanism for JSON? I.e., now we have one for serialize(), separate one for json, then we'd have separate one for storing object as XML or YAML, etc. etc. IMHO it's not a very good design - having separate method for every format of data storage. Why can't we just use whatever serialize() would see and wrap it in JSON after that? Because there's no reason to believe that you want serialize() to capture the same data as json_encode().