Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52888
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 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:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=NmLCEk/B8qjjKPGE3EV6iVsjZmMCDZ0XnsZdBCd9JuVr32ecPqk94/E2qa62UeobOh
         o5iNStEhNGGMxaPn8Fkx5pjDDYNaDIxRXS/5F2kk1+hzVqZdOKa/gmbwe/ur+HNFB4Un
         IoWqjtvuVv9rbdyT/2MOnCreQVdyRx+Tbk0Xw=
MIME-Version: 1.0
In-Reply-To: <073E2169-A50B-4139-851D-F62CF30189F4@bitextender.com>
References: <BANLkTimxaaMTbWyhs=0tnZiCGyPwAsARqA@mail.gmail.com>
	<073E2169-A50B-4139-851D-F62CF30189F4@bitextender.com>
Date: Sat, 4 Jun 2011 12:32:09 -0400
Message-ID: <BANLkTi=yyz+_EV73uB6CW54_4hc7iabk4Q@mail.gmail.com>
To: =?ISO-8859-1?Q?David_Z=FClke?= <david.zuelke@bitextender.com>
Cc: dukeofgaming <dukeofgaming@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] JSON array/object syntax
From: ircmaxell@gmail.com (Anthony Ferrara)

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 se=
ems that those demanding it somehow confuse or blur the lines between the d=
eclaration of data in the language and its representation in a serializatio=
n format. A few people in the thread demanded that it be a syntax that coul=
d also be consumed by all the JSON parsers out there, and I have no idea ho=
w that would be useful at all, since the construct per se isn't useful at a=
ll as PHP code and at least needs to be wrapped in <?php and ?> tags, so yo=
u couldn't just evaluate it as JavaScript (which would be useless without a=
ssignment etc).
>
> I ignored that aspect as others covered it already (e.g. Pierre asking wh=
at the point was of this at all) and focused on the encoding issue that *wo=
uld* occur if someone, somehow managed to find a useful way of taking advan=
tage of such a notation (e.g. where it would be interchangeable with JS cod=
e 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 t=
o 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=FClke's example it see=
ms
>> more like a pure-unicode issue to me:
>>
>> ----
>>
>> It is different from writing json_decode('=E4\u0123'), because json_deco=
de()
>> 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) {
>>> =A0[0]=3D>
>>> =A0string(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), 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 wi=
ll
>> 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
>
>