Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42296
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.132.250 cause and error)
Cc: RQuadling@GoogleMail.com,
 PHP Developers Mailing List <internals@lists.php.net>
Message-ID: <CF09236D-9251-4B3B-BB31-39B3BEC60EAD@prohost.org>
To: Scott MacVicar <scott@macvicar.net>
In-Reply-To: <494797BE.3060505@macvicar.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 16 Dec 2008 11:37:31 -0500
References: <494698D3.2030801@lerdorf.com>	 <bd9320b30812151009t29bc6283m79f8985022cd7e2b@mail.gmail.com> <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com> <494797BE.3060505@macvicar.net>
Subject: Re: [PHP-DEV] json_encode()
From: ilia@prohost.org (Ilia Alshanetsky)

The proposed solution (basic types flag) is probably the lesser evil,  
but I still feel were are taking things to far and current operation  
is correct.


On 16-Dec-08, at 6:57 AM, Scott MacVicar wrote:

> 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
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ilia Alshanetsky