Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42292
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 72.14.220.152 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to
         :mime-version:content-type:content-transfer-encoding
         :content-disposition:references:x-google-sender-auth;
        b=HnRvJb+zIl3FdSemvSNwEu8jj6O1QEVZgaz9jr7JFXDlasMF4k/7KKbkJsWIARH6Uj
         6uA1VBVxOSC2CyrVMZMpx1fHYfeGoO/rBxFcc1kqGn3ZY+OQEQuqcOwYZwpIjGxpNUUn
         WoV95ykQt53uF9gVYg3aQ2LxfAfsB9s5PgQgk=
Message-ID: <b19eae4e0812160707t725aa8d4j688de719061f2808@mail.gmail.com>
Date: Tue, 16 Dec 2008 15:07:15 +0000
Reply-To: viroteck@viroteck.net
Sender: surreal.w00t@gmail.com
To: RQuadling@googlemail.com
Cc: "Scott MacVicar" <scott@macvicar.net>, 
	"PHP Developers Mailing List" <internals@lists.php.net>
In-Reply-To: <10845a340812160606k393ddcedq5fa6a1223392c992@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <494698D3.2030801@lerdorf.com>
	 <bd9320b30812151009t29bc6283m79f8985022cd7e2b@mail.gmail.com>
	 <10845a340812160348k18bffb0et1e75cf345b5e42cc@mail.gmail.com>
	 <494797BE.3060505@macvicar.net>
	 <10845a340812160606k393ddcedq5fa6a1223392c992@mail.gmail.com>
Subject: Re: [PHP-DEV] json_encode()
From: viroteck@viroteck.net ("Robin Burchell")

Settings which change behaviour like that aren't really all that fun
for third party/portable applications developers, e.g. forum software
and the likes. magic_quotes_gpc and others are good examples of this.

Going back to Rasmus' mail based on his discussion with Douglas, I
think that option #1 (documenting the way it works, and documenting
how to do things "properly") sounds perfectly fine.

On Tue, Dec 16, 2008 at 2:06 PM, Richard Quadling
<rquadling@googlemail.com> wrote:
> 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!"
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>