Re: Removing basic types from our JSON parser

> > I'm not sure if that is the right way of looking at it though. I think > the only question is how to represent the scalar types, not whether they > should be allowed. As far as I am concerned it is obvious that they be > allowed and the JSON spec is quite explicit that JSON can be used to > represent scalar types: > > JSON can represent four primitive types (strings, numbers, > booleans, and null) and two structured types (objects and arrays). > > The only question is how to serialize these into a JSON-text string. > Again, from the RFC: > > A JSON text is a sequence of tokens. The set of tokens includes six > structural characters, strings, numbers, and three literal names. > > A JSON text is a serialized object or array. > > This last statement is the issue. When serializing a basic type into a > JSON text string, the RFC says we need to wrap it inside an array or > object. So, if we are going to add an option to json_encode(), that's > what the option should do. Specify whether, and perhaps how, to wrap > basic types, not whether to allow or disallow them. > > I'll talk to Douglas on Monday if he is in the office and get his opinion. > > -Rasmus cool. let's see how :D. Crockford explain it :D but before he can react on this thread, i guess Rasmus is right understanding the RFC. json force your encoder to output the following in encoded form 1. array: "multiple of unnamed" values 2. object: "multiple of named" values so it's right to "wrap it" in object or array (u can say "remove basic types") json_encode(array(1)); => [1] json_encode(array(1, 2, 3, "1")); => [1,2,3,"1"] json_encode(array('value1' => 1)); => {"value1":1} json_encode(array('a'=>1, 'b'=>2, 'c'=>3, 'd'=>"1")); => {"a":1, "b":2,"c":3,"d":"1"} i'd prefer 2 new functions: js_encode (or js_export?) js_decode which support basic types instead of having an extra optional parameter