Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53026
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.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=s0C9ciYcl0x0BG09+9ivCkYCbQcb4KsDZdkPHi4vBwNjVvshxJnVtH/BKLHljz5I/r
         FdZPXNfD2KUcF/2K129KxpVlt2Kx3Kbr75emNCEEae36x34rYqOt5yNPRKvI3SLSeYyS
         VaDZWE5G7zFhtO1I/2hQQaqdScipoRT7epGFw=
MIME-Version: 1.0
In-Reply-To: <F23650CF-CFD4-4D63-AA52-1B9477A8C787@seancoates.com>
References: <1181529113.20110605190617@cypressintegrated.com> <F23650CF-CFD4-4D63-AA52-1B9477A8C787@seancoates.com>
Date: Mon, 6 Jun 2011 09:23:21 -0500
Message-ID: <BANLkTinn5EuOwN0JWt6MiJt4RTrmSS0ffg@mail.gmail.com>
To: Sean Coates <sean@seancoates.com>
Cc: Sanford Whiteman <sandy@cypressintegrated.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016367ed58e9ed01904a50bd986
Subject: Re: [PHP-DEV] Object and Array Literals
From: dukeofgaming@gmail.com (dukeofgaming)

--0016367ed58e9ed01904a50bd986
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jun 6, 2011 at 8:48 AM, Sean Coates <sean@seancoates.com> wrote:
>
> 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).
>

Still, it is mentioned so many times that it could be unintentionally
misleading IMHO.


>
> 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.
>

Can you provide an use case and code example of how that would look?


>
> > Somewhat on a side note, I do not understand the statement that
> >
> >    "using a strict syntax would not conform with the PHP way"
> >
> > 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 => 1)
> PHP: array('foo' => 1)
>
> (For anyone who doesn't follow, correct way in JSON is to use " not '.)
>
> Thanks for the comments.
>

As mentioned earlier, I think the resemblance to JSON is just a happy
coincidence, the syntax makes enough sense by itself. You can argument that
its familiarity/friendliness/ubiquity makes it a good option, but in its
current state (i.e. not defining why JSON compatibility is justified) I'd
say it is not complete.

Regards,

David

--0016367ed58e9ed01904a50bd986--