On Sat, Sep 10, 2011 at 3:13 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
On 11-09-09 10:00 PM, Daniel Friesen wrote:
On 11-09-09 06:22 PM, Andrew Garrett wrote:
On Thu, Sep 8, 2011 at 8:36 PM, Max Semenik maxsem.wiki@gmail.com wrote:
Even though data in those fields is small enough, can serialize()/unserialize() be used instead? It's faster and doesn't require the mess of ServicesJSON to work correctly.
I'd prefer JSON. I don't care about the speed, it's not a critical code path, and JSON is stable, well-defined and can be read by any client, whereas serialize is some scary PHP format that may or may not change without notice.
- We already (un)serialize data in and out of the database.
- (un)serialize can't change, if it does we already have problems.
- These are for database storage we have no reason to input data into a
private database in a format expecting people to read the data back from other clients.
- json in php requires a mess of code and potentially a 3rd party
libraries because: -- the bulit-in json json_{en,de}code library functions may not be installed -- the bulit-in json library in some cases actually has a bug that makes it encode/decode json incorrectly
Here's another kick:
- Using JSON in php, when you decode what you encoded you don't always
get the same thing back (serialize you of course do)
var_dump(FormatJson::encode(array(1=>1,2=>2)));
string(13) "{"1":1,"2":2}" var_dump(FormatJson::decode('{"1":1,"2":2}')); object(stdClass)#20 (2) { ["1"]=> int(1) ["2"]=> int(2) }
array in, object out.
There is a FormatJson argument to return assoc arrays instead of objects, but this means rather than always getting the right type of data back you have to specifically note when you want assoc arrays and when you want objects.
Only mildly annoying, and not enough of a reason to stop using JSON imo. That's the behavior of json_decode() anyway, so we're not diverging from upstream.
-Chad