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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
