Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52972
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :cc:content-type;
        b=cKHhrHZPZsPGo2sme2WnuQo0mZvqjj1uFp1UzTGX5N93dv+RHGikZ90zGrf+Cyy+s2
         884y4YBro/R/58ji9sb32mqsw5PO2fAFRruqt5PgBJnZ59EaKZLCj/K3w2NnHDjvumf7
         efjKZuNkSpn2h9jOeL6Doyt1uVOEcc8dWMdDE=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=yyz+_EV73uB6CW54_4hc7iabk4Q@mail.gmail.com>
References: <BANLkTimxaaMTbWyhs=0tnZiCGyPwAsARqA@mail.gmail.com>
 <073E2169-A50B-4139-851D-F62CF30189F4@bitextender.com> <BANLkTi=yyz+_EV73uB6CW54_4hc7iabk4Q@mail.gmail.com>
Date: Sun, 5 Jun 2011 16:11:51 -0500
Message-ID: <BANLkTikTdCAGJjGnMLs-433AJi5uMmwjOw@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: =?ISO-8859-1?Q?David_Z=FClke?= <david.zuelke@bitextender.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6d3de5ab0353704a4fd701e
Subject: Re: [PHP-DEV] JSON array/object syntax
From: dukeofgaming@gmail.com (dukeofgaming)

--0016e6d3de5ab0353704a4fd701e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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.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=FClke
> <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 t=
he
> 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 t=
o
> be
> >> the same seems useless to me, and reading David Z=FClke's example it s=
eems
> >> more like a pure-unicode issue to me:
> >>
> >> ----
> >>
> >> It is different from writing json_decode('=E4\u0123'), because
> json_decode()
> >> in PHP only accepts UTF-8 encoded input;
> >>
> >> Give it a shot:
> >>
> >> <?php
> >> $chr =3D "\xC3\xA4"; // "=E4" as UTF-8
> >> var_dump(json_decode('["' . $chr . '\u00e4"]'));
> >> var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
> >> ?>
> >>
> >> That'll produce:
> >>
> >>> array(1) {
> >>>  [0]=3D>
> >>>  string(4) "=E4=E4"
> >>> }
> >>> NULL
> >>
> >> Understand what the problem is now?
> >>
> >> If someone does this in a latin1-encoded file:
> >>
> >> <?php $fancyNewArray =3D {"yay": "=E4"}; ?>
> >>
> >> Then that is valid as a PHP array (as it's a latin1 "=E4", so \xE4), b=
ut
> >> 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 concre=
te
> &
> >> punctualized examples the advantages of having such JSON approach to
> PHP.
> >>
> >> Regards,
> >>
> >> David Vega
> >
> >
>

--0016e6d3de5ab0353704a4fd701e--