Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42290
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.218.21 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:reply-to:to:subject:cc:in-reply-to
         :mime-version:content-type:content-transfer-encoding
         :content-disposition:references;
        b=tpCOJK5Vgl+NYzOncVcZ+cAxaOHV4sNdYMONVFd2kQ+Q8rSCzXvyQ3L0Db8ejmZfu6
         WkzpEqtJ35e6ukh23KAr3x6gaNg76lu0P0URgxDo2PZ36h805JBZzwau6zCXjnXsbaod
         obF/BPUMW0ZlxFb4mgV3zIRN7eUewFu09Rhd4=
Message-ID: <10845a340812160606k393ddcedq5fa6a1223392c992@mail.gmail.com>
Date: Tue, 16 Dec 2008 14:06:44 +0000
Reply-To: RQuadling@GoogleMail.com
To: "Scott MacVicar" <scott@macvicar.net>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
In-Reply-To: <494797BE.3060505@macvicar.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <494698D3.2030801@lerdorf.com>
	 <bd9320b30812151009t29bc6283m79f8985022cd7e2b@mail.gmail.com>
	 <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com>
	 <494797BE.3060505@macvicar.net>
Subject: Re: [PHP-DEV] json_encode()
From: rquadling@googlemail.com ("Richard Quadling")

2008/12/16 Scott MacVicar <scott@macvicar.net>:
> 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.

When I say "expect", it was because the PHP documentation said I could.

I like the option to either have strict encoding as standard or as an
option I can activate myself. Either way, I want to be told if I've
done it wrong.

> 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);

+1

Would it be at all possible to have an ini setting json.strict_encode = On

So, my code doesn't change, but I can activate it globally.
Essentially I don't want to shoot myself. I don't want to take the
safety off.
>
> Scott
>



-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"