Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52990
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 69.28.242.152 as permitted sender)
Date: Sun, 5 Jun 2011 19:06:17 -0400
Organization: Cypress Integrated Systems, Inc.
Message-ID: <1181529113.20110605190617@cypressintegrated.com>
To: PHP internals <internals@lists.php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Object and Array Literals
From: sandy@cypressintegrated.com (Sanford Whiteman)

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 --

=B7  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;

=B7    recognizably    violates   JSON   quoting   rules,   not   as   a
secondary/optional  syntax,  but  in the primary examples given in the
RFC; and

=B7  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 --

=B7  is  recognizably  similar  to  JavaScript  object  literal  syntax,
especially wrt quotation marks, with the notable exception of allowing
interpolation/invocation on LHS;

=B7  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;

=B7  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

=B7 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:

=B7 JavaScript-like [object|array] literal syntax
=B7 bare-bracket [object|array] literal syntax
=B7 short [object|array] literal syntax
=B7 compact [object|array] ...
=B7 quick [object|array] ...
=B7 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.