re "JSON"
> · will never validate as JSON
>
> · recognizably violates JSON quoting rules
> · recognizably violates the JSON security concept…
…
> -- 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
>
> "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.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
