Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42243
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.142.185 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references:x-google-sender-auth;
        b=CVV0vUn5HApLHVVFdwh0kIwypdWZBaWRzYcaWQ67Oj3lYna+I0AKfe/ew5bnS6oRJn
         MrAoV4z3vCB/5WWPdEnJxzMSYJRvU6CeV2AGaJgX+SUFXmv2RC1KVgn99khQHfvf4sFm
         MEAthB0JvkeyqVTF3KhG+t9AAtU2bA7LoWEiI=
Message-ID: <28139bc0812132210p1ed94f4ds40e31ff499cf2e7@mail.gmail.com>
Date: Sun, 14 Dec 2008 14:10:38 +0800
Sender: xuefer@gmail.com
To: "Rasmus Lerdorf" <rasmus@lerdorf.com>
Cc: "Stan Vassilev | FM" <sv_forums@fmethod.com>, 
	"PHP Developers Mailing List" <internals@lists.php.net>
In-Reply-To: <49448D66.2030501@lerdorf.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net>
	 <1229150500.30719.201.camel@localhost>
	 <4BA26FE8A9634178B4CEBEFA818810D2@VEGA>
	 <15E310EAB433466EAF996B252CBED2BB@pc> <49448D66.2030501@lerdorf.com>
Subject: Re: [PHP-DEV] Removing basic types from our JSON parser
From: moo.tinys@gmail.com (moo . tinys)

>
> 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