As ordered, I will stick to what I feel are community issues and try
to be impersonal.
If PHP users want to be clear that we have made an educated choice to
use/maintain the language, we should appear impeccably well-versed in
the technologies which complement and compete with PHP. I feel
strongly that one should use the best-fit terminology when referring
to outside technologies whenever possible, avoiding poorer-fit
misnomers.
In the case of syntax that --
· will never validate as JSON -- a syntax which is the subject of a
well-trafficked IETF RFC; has no standardized non-strict/quirks/
compatibility mode that would suggest that the term can have multiple
meanings; and has no understood history of multiple meanings by
experts in its use;
· recognizably violates JSON quoting rules, not as a
secondary/optional syntax, but in the primary examples given in the
RFC; and
· recognizably violates the JSON security concept that "excludes
assignment and invocation" [RFC 4627] when using host variables or
function invocations on LHS or RHS
-- yet --
· is recognizably similar to JavaScript object literal syntax,
especially wrt quotation marks, with the notable exception of allowing
interpolation/invocation on LHS;
· thanks to recent major moves in server-side JS (nodeJS), does not
need a poor-fit comparison to an interchange/serialization format in
order to be understood, but can be recognized as JS-like by
server-side folks;
· allows PHP string interpolation within RHS, which is not in direct
conflict with JS object literal syntax -- as JS simply doesn't support
interpolation that would have to be allowed/denied in this context --
but which is in direct conflict with the JSON standard, which
conceptually denies such dereferencing; and
· insofar as it does directly conflict with JS object literal rules in
allowing the LHS (key) of a key:value pair to contain variables or
function invocations, still does not add or allow anything that is
allowed in JSON, as JSON is more restrictive than JS object literals
and prohibits all these syntaxes and more
-- I do not feel that the acronym JSON has any clarifying nor edifying
place in the RFC describing this syntax.
Rather, I would suggest one of the following:
· JavaScript-like [object|array] literal syntax
· bare-bracket [object|array] literal syntax
· short [object|array] literal syntax
· compact [object|array] ...
· quick [object|array] ...
· colon-pair [object|array] ...
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.
It might also be noted (h/t David Vega) that Ruby adopted a syntax
similar to that proposed here and completely avoided using the term
JSON in final documentation, as I hope will be done with PHP even if
this RFC continues to use the term.
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.
It is my understanding that, while concepts including (but not limited
to) type-juggling, dynamic typing, and use of undeclared vars are
emblematic of the PHP way, what I would call "strict syntax[es]" are
encouraged in many areas (without E_STRICT). For one example, missing
semicolons may be fatal in PHP while symmetrical syntax works in JS.
For another one off the top, PHP's XML modules require well-formedness
by default, not what I would expect if there were such a thoroughgoing
loose approach to syntax.
-- S.
On Sun, Jun 5, 2011 at 6:06 PM, Sanford Whiteman <
sandy@cypressintegrated.com> wrote:
-- I do not feel that the acronym JSON has any clarifying nor edifying
place in the RFC describing this syntax.Rather, I would suggest one of the following:
· JavaScript-like [object|array] literal syntax
· bare-bracket [object|array] literal syntax
· short [object|array] literal syntax
· compact [object|array] ...
· quick [object|array] ...
· colon-pair [object|array] ...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.
It might also be noted (h/t David Vega) that Ruby adopted a syntax
similar to that proposed here and completely avoided using the term
JSON in final documentation, as I hope will be done with PHP even if
this RFC continues to use the term.
Bravo for ponting that out, your argument has cleared my mind a little while
trying to understand this side (I'm actually against the JSON
interoperability argument [because it does not make sense to me], but not
the syntax).
After reading this new RFC and pondering about the JSONy implications, the
multi-part conclusion that I reached is that:
a) JSON is actually being mentioned to advocate for the syntax with for the
sake of familiarity.
b) Interoperability is being confused with familiarity.
c) Actual interoperability of the syntax with JSON is just a happy
coincidence (same as with Ruby)
d) In no context this notation could function as JSON and PHP at the same
time, mainly because PHP requires tags
e) There is a strong resistance to change, I bet the detractors of this
short syntax (even with the ":") would change their opinion after using it,
just the way some of us used to hate the idea of namespaces with "" and
after using it changed our opinion (specially with the autoloading standard
that actually reflects file structure, e.g. in Symfony2).
f) If JSON ceased to exist in this very moment, supporters of the syntax
would be still supporting it and perhaps detractors would accept it.
The effect of mentioning JSON, and implying direct compatibility with JSON
technologies and JSON itself is just adding FUD.
+1 to removing references to JSON from the RFC, because "[ ]", "{ }" and ":"
make enough sense by themselves.
Regards,
David Vega
a) JSON is actually being mentioned to advocate for the syntax with for the
sake of familiarity.
b) Interoperability is being confused with familiarity.
My goal is interoperability. Familiarity is a factor, definitely.
c) Actual interoperability of the syntax with JSON is just a happy
coincidence (same as with Ruby)
I disagree; see below.
d) In no context this notation could function as JSON and PHP at the same
time, mainly because PHP requires tags
I don't think they could be interchangeable, programmatically, as files, but copying and pasting from PHP to curl for ElasticSearch would have saved me hours of back-and-forth over the past months.
e) There is a strong resistance to change, I bet the detractors of this
short syntax (even with the ":") would change their opinion after using it,
just the way some of us used to hate the idea of namespaces with "" and
after using it changed our opinion (specially with the autoloading standard
that actually reflects file structure, e.g. in Symfony2).
Absolutely agree. In addition, for me to see the value in this, it took more than just knowing how it worked, but immersing myself in this syntax (really wanting it).
When short array syntax was first proposed, I didn't care. As I've said here a couple times, this is not about saving 5 characters by changing "array(" into "[", but about many other things.
f) If JSON ceased to exist in this very moment, supporters of the syntax
would be still supporting it and perhaps detractors would accept it.The effect of mentioning JSON, and implying direct compatibility with JSON
technologies and JSON itself is just adding FUD.
I don't want blanket compatibility. I do want to be able to write PHP that CAN be passed off to third-parties verbatim, if care is taken to do so. Most of the time I use JSON, this care is not required, though. I don't think it's FUD, but I do see your point in that the term "JSON" is strangely offensive to some, and I would be willing to remove it (but not if only you two think this way).
+1 to removing references to JSON from the RFC, because "[ ]", "{ }" and ":"
make enough sense by themselves.
S
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
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
Can you provide an use case and code example of how that would look?
Sure.
Here's how an ElasticSearch query currently looks in PHP:
$esQuery = new \StdClass;
$esQuery->query = new \StdClass;
$esQuery->query->term = new \StdClass;
$esQuery->query->term->name = 'beer';
$esQuery->size = 1;
// OR
$esQuery = (object)array(
"query" => (object)array(
"term" => (object)array(
"name" => "beer"
)
),
"size" => 1
);
…and here's how it could look with the proposed syntax:
<?php
$esQuery = {
"query" : {
"term" : {
"name": "beer"
}
},
"size" : 1
};
…and here's how I'd use curl to ensure that the query I'm issuing does in fact work with ElasticSearch:
$ curl http://localhost:9200/gimmebar/assets/_search?pretty=1 -d'{
"query" : { "term" : { "name": "beer" } }, "size" : 1}'
Even considering the (object)array( syntax, it's much easier to work with an external query (as shown with curl), if we have a (nearly) JSON-compatible syntax in PHP.
Note that I could have written the PHP definition of $esQuery with the proposed syntax and non-JSON compatible syntax (single quotes, for example), but I chose to write it with double quotes because I knew I might also want to pass it to curl.
Realistically, "beer" would be in a variable (maybe {"term": {"name": $term}}), but replacing just the variables is certainly much easier than translating the new \StdClass syntax.
The argument for right-hand-side assignments being allowed in the proposed syntax (such as in {'time':time()}) is still valid because I expect this syntax will be used both for interoperating with third party services (as above), but also generally for object and array creation without a care about third parties.
S