On Sat, Sep 10, 2011 at 3:13 AM, Daniel Friesen
<lists(a)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(a)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