JSON array/object syntax

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 ircmaxell@gmail.comwrote:

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.zuelke@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

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