Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42247
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <4944AD36.7070406@lerdorf.com>
Date: Sat, 13 Dec 2008 22:52:38 -0800
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: mike <mike503@gmail.com>
CC: "moo.tinys" <moo.tinys@gmail.com>,
        Stan Vassilev | FM <sv_forums@fmethod.com>,
        PHP Developers Mailing List <internals@lists.php.net>
References: <2D85B33E-889B-4214-9BB8-A12EFFFC641E@macvicar.net> <1229150500.30719.201.camel@localhost> <4BA26FE8A9634178B4CEBEFA818810D2@VEGA> <15E310EAB433466EAF996B252CBED2BB@pc> <49448D66.2030501@lerdorf.com> <28139bc0812132210p1ed94f4ds40e31ff499cf2e7@mail.gmail.com> <7463F1E1-A880-479F-9584-30FFCED6E614@gmail.com> <4944AA37.9030400@lerdorf.com> <234C8048-A00D-4AEE-A23E-5FA10EA85D6D@gmail.com>
In-Reply-To: <234C8048-A00D-4AEE-A23E-5FA10EA85D6D@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Removing basic types from our JSON parser
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Yes, but that would be going to a json_parse thing somewhere, not pure
Javascript.

-Rasmus

mike wrote:
> I can't give specifics (I'm mobile and I don't remember where the code
> would be anyway) but we had an issue with php and javascript exchange
> via json where the php output using json_encode and we had to wrap it
> with additional braces for it to be usable. Sorry for being vague, this
> thread reminded me of that which is why I wanted to voice off.
> 
> Thanks for the clarification (and thank you so much for PHP :))
> 
> On Dec 13, 2008, at 10:39 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> 
>> mike wrote:
>>> Sorry for top posting. I see no reason why php should not interop with
>>> javascript 100% as it should. I do not see a reason to create new
>>> functions, parameters, etc. The existing should be expected to both
>>> encode and decode json with javascript properly. If there is a mismatch
>>> right now, then it should be fixed.
>>
>> There is no mismatch with Javascript now at all.  We spit out perfectly
>> valid Javascript.  There is only a slight mismatch with the JSON RFC
>> which defines a stricter subset of Javascript than we are using.
>>
>> -Rasmus