Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42285
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain macvicar.net from 193.227.246.108 cause and error)
Message-ID: <494797BE.3060505@macvicar.net>
Date: Tue, 16 Dec 2008 11:57:50 +0000
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: RQuadling@GoogleMail.com
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <494698D3.2030801@lerdorf.com>	 <bd9320b30812151009t29bc6283m79f8985022cd7e2b@mail.gmail.com> <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com>
In-Reply-To: <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam_Report: Spam detection software, running on the system "lovelace.midden.org.uk", has
	identified this incoming email as possible spam.  The original message
	has been attached to this so you can view it (if it isn't spam) or label
	similar future email.  If you have any questions, see
	the administrator of that system for details.
	Content preview:  Richard Quadling wrote: > 2008/12/15 mike <mike503@gmail.com>:
	>> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
	>> >>> 1. Document the fact that if you want to strictly conform to the JSON
	>>> spec and be sure your json_encode output will work in various JSON >>>
	parsers, you have to pass it a PHP array or object. >> Instead of json_encode(34)
	the suggestion would be >> json_encode(array(34)) ? Seems kind of like a
	lame thing to require. >> IMHO the language should "do the right thing" as
	far as the consumer >> (javascript/JSON parser) is concerned. However, Douglas
	is infinitely >> more educated than I am here. This is just my $0.02 as a
	PHP user. > > I was one of those that read the PHP dox and not the RFC/standard
	> (http://bugs.php.net/bug.php?id=38680). > > I would say that having PHP
	"correct" my mistake is wrong. > > If I say... > > json_encode(34); > > I
	am saying that I expect the result to be ... > > var i_SomeInt = 34; > >
	And from there I would expect to be able to say ... > > var i_SomeOtherInt
	= i_SomeInt + 10; > > This is not going to work if PHP "corrects" my mistake.
	> > I'd be perfectly happy for the standard to be enforced and an E_STRICT
	> warning to be raised. > > If I want to shoot myself then I have to at least
	take the safety off > first - turning off E_STRICT that is. > > Essentially,
	I don't like computers guessing my intent. If I don't > state it clearly
	enough then it may be that I don't know what I'm > doing. > > GIMGO (Garbage
	In, Maybe Garbage Out) isn't a good way to go. > [...] 
	Content analysis details:   (-4.3 points, 5.0 required)
	pts rule name              description
	---- ---------------------- --------------------------------------------------
	-1.8 ALL_TRUSTED            Passed through trusted hosts only via SMTP
	-2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
	[score: 0.0000]
	0.1 AWL                    AWL: From: address is in the auto white-list
Subject: Re: [PHP-DEV] json_encode()
From: scott@macvicar.net (Scott MacVicar)

Richard Quadling wrote:
> 2008/12/15 mike <mike503@gmail.com>:
>> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
>>
>>> 1. Document the fact that if you want to strictly conform to the JSON
>>>   spec and be sure your json_encode output will work in various JSON
>>>   parsers, you have to pass it a PHP array or object.
>> Instead of json_encode(34) the suggestion would be
>> json_encode(array(34)) ? Seems kind of like a lame thing to require.
>> IMHO the language should "do the right thing" as far as the consumer
>> (javascript/JSON parser) is concerned. However, Douglas is infinitely
>> more educated than I am here. This is just my $0.02 as a PHP user.
> 
> I was one of those that read the PHP dox and not the RFC/standard
> (http://bugs.php.net/bug.php?id=38680).
> 
> I would say that having PHP "correct" my mistake is wrong.
> 
> If I say...
> 
>  json_encode(34);
> 
>  I am saying that I expect the result to be ...
> 
> var i_SomeInt = 34;
> 
> And from there I would expect to be able to say ...
> 
> var i_SomeOtherInt = i_SomeInt + 10;
> 
> This is not going to work if PHP "corrects" my mistake.
> 
> I'd be perfectly happy for the standard to be enforced and an E_STRICT
> warning to be raised.
> 
> If I want to shoot myself then I have to at least take the safety off
> first - turning off E_STRICT that is.
> 
> Essentially, I don't like computers guessing my intent. If I don't
> state it clearly enough then it may be that I don't know what I'm
> doing.
> 
> GIMGO (Garbage In, Maybe Garbage Out) isn't a good way to go.
> 

json_encode is NOT javascript encode, you're already shooting yourself
by miusing the function. The problem I'm talking about here is when
native browser functions are used to decode the JSON.

var json_resonse = <?php echo json_encode(42); ?>;
var myfoo = JSON.parse(json_resonse);

The result here is an exception thrown by the browser, if you try and
use JSON to speak to perl, python or ruby you get a similar error. The
same applies for the various frameworks out there too.

For now I'll be leaving it as is and adding a JSON_STRICT_ENCODE
parameter to the options flag. So you can use

json_encode($var, JSON_STRICT_ENCODE);

Scott