Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53022
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain seancoates.com from 64.15.79.181 cause and error)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
In-Reply-To: <1181529113.20110605190617@cypressintegrated.com>
Date: Mon, 6 Jun 2011 09:48:36 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F23650CF-CFD4-4D63-AA52-1B9477A8C787@seancoates.com>
References: <1181529113.20110605190617@cypressintegrated.com>
To: Sanford Whiteman <sandy@cypressintegrated.com>
Subject: Re: [PHP-DEV] Object and Array Literals
From: sean@seancoates.com (Sean Coates)

re "JSON"

> =B7  will  never  validate as JSON
>=20
> =B7    recognizably    violates   JSON   quoting   rules

> =B7  recognizably  violates  the  JSON  security  concept=85

=85

> -- I do not feel that the acronym JSON has any clarifying nor edifying
> place in the RFC describing this syntax.


> I have actually been excited about the discussion of this feature area
> and anticipate my eventual +1 if "JSON" could be removed from the RFC.
> Even  though  the  term  doesn't  affect the way the feature works, by
> upvoting  the  RFC one is approving of wording that may make it to the
> general public, and I think this would be bad for PHP.

I was careful in the RFC to indicate that this is *not* JSON, but if =
others feel as strongly as you do about the use of this term, I think it =
can be removed without hurting the idea (as you indicated).

You're right that the RFC does not declare a syntax that will always =
validate as JSON, nor does it respect serialization rules, but I see it =
more as a declaration syntax than a serialization format, as it is =
proposed. The real goal is to improve interaction with third parties, =
which I think the proposed syntax would allow.

That said, other than the \u syntax, I believe that the proposed =
declaration syntax would still allow JSON from a third party to me =
interpreted by PHP, in a way that makes sense in PHP.

> Somewhat on a side note, I do not understand the statement that
>=20
>    "using a strict syntax would not conform with the PHP way"
>=20
> or at least how it relates to this RFC.

This is directly related to the JSON-non-strictness that everyone seems =
to want (me included). For example the following is completely invalid =
in JSON, but normally OK (for small values of OK) in PHP:

(not-)JSON: {foo: 1}
(not-)JSON: {'foo': 1}
PHP: array(foo =3D> 1)
PHP: array('foo' =3D> 1)

(For anyone who doesn't follow, correct way in JSON is to use " not '.)

Thanks for the comments.

S=