Ok, I found that Ruby added support for a new JSONy syntax a little while ago, this is interesting:
http://www.strictlyuntyped.com/2010/12/new-ruby-19-hash-syntax.html http://webonrails.com/2009/02/06/ruby-191-hash/ But it doesn't have anything to do with JSON interoperability. On Sat, Jun 4, 2011 at 11:32 AM, Anthony Ferrara <ircmax...@gmail.com>wrote: > One advantage would be familiarity. New developers only need to worry > about 1 syntax, rather than a new one for each language. I'm not > saying if it's worth it or not, but there is something to be said for > consistency and using already established patterns and syntaxes if it > makes sense (aka: there is no compelling reason not to). So far I > haven't seen any compelling reason not to do it. Not saying they > aren't there, nor that there aren't justifiable reasons in the > threads. Just that I don't find any of the reasons against it > compelling enough to say it doesn't make sense to use a json-style > syntax. > > Just my 0.02... > > On Sat, Jun 4, 2011 at 7:52 AM, David Zülke > <david.zue...@bitextender.com> wrote: > > To clarify: I don't understand what the advantage would be, either. It > seems that those demanding it somehow confuse or blur the lines between the > declaration of data in the language and its representation in a > serialization format. A few people in the thread demanded that it be a > syntax that could also be consumed by all the JSON parsers out there, and I > have no idea how that would be useful at all, since the construct per se > isn't useful at all as PHP code and at least needs to be wrapped in <?php > and ?> tags, so you couldn't just evaluate it as JavaScript (which would be > useless without assignment etc). > > > > I ignored that aspect as others covered it already (e.g. Pierre asking > what the point was of this at all) and focused on the encoding issue that > *would* occur if someone, somehow managed to find a useful way of taking > advantage of such a notation (e.g. where it would be interchangeable with JS > code or be evaluated as JSON by other JSON parsers) - namely the problem > that you could produce *PHP code*, that, with some mingling and stripping, > *PHP's own json_decode() could not process*. > > > > Perhaps I should have made that more clear, sorry. > > > > David > > > > > > On 04.06.2011, at 03:17, dukeofgaming wrote: > > > >> Hi, > >> > >> After reading all the debate in the other thread it is still not clear > to me > >> what the real advantages are of adopting JSON syntax for native PHP > >> types. Doing json_encode to an object and expect the code and output to > be > >> the same seems useless to me, and reading David Zülke's example it seems > >> more like a pure-unicode issue to me: > >> > >> ---- > >> > >> It is different from writing json_decode('ä\u0123'), because > json_decode() > >> in PHP only accepts UTF-8 encoded input; > >> > >> Give it a shot: > >> > >> <?php > >> $chr = "\xC3\xA4"; // "ä" as UTF-8 > >> var_dump(json_decode('["' . $chr . '\u00e4"]')); > >> var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]')); > >> ?> > >> > >> That'll produce: > >> > >>> array(1) { > >>> [0]=> > >>> string(4) "ää" > >>> } > >>> NULL > >> > >> Understand what the problem is now? > >> > >> If someone does this in a latin1-encoded file: > >> > >> <?php $fancyNewArray = {"yay": "ä"}; ?> > >> > >> Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but > >> cannot be consumed by PHP's json_decode(). And that would be terribly > >> inconsistent behavior. > >> > >> ----- > >> > >> It looks more like you want to do json_decode to PHP code hoping that > will > >> somehow fix json_decode... instead of fixing json_decode. > >> > >> Could someone advocating this please explain with use-cases and concrete > & > >> punctualized examples the advantages of having such JSON approach to > PHP. > >> > >> Regards, > >> > >> David Vega > > > > >
