Re: Object and Array Literals

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