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 <rquadl...@googlemail.com> wrote: > 2008/12/16 Scott MacVicar <sc...@macvicar.net>: >> Richard Quadling wrote: >>> 2008/12/15 mike <mike...@gmail.com>: >>>> On Mon, Dec 15, 2008 at 9:50 AM, Rasmus Lerdorf <ras...@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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
