# Object and Array Literals

- Thread: https://externals.io/message/52990
- Original archive: https://news-web.php.net/php.internals/52990
- Started by Sanford Whiteman on 2011-06-05T23:06:17+00:00
- Messages: 6
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #52990 — Sanford Whiteman — 2011-06-05T23:06:17+00:00

URL: https://externals.io/message/52990#52990

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.

---

## #52995 — dukeofgaming — 2011-06-05T23:58:54+00:00

URL: https://externals.io/message/52990#52995 · In reply to: #52990

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

---

## #53022 — Sean Coates — 2011-06-06T13:48:36+00:00

URL: https://externals.io/message/52990#53022 · In reply to: #52990

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

---

## #53023 — Sean Coates — 2011-06-06T13:59:37+00:00

URL: https://externals.io/message/52990#53023 · In reply to: #52995

> 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

---

## #53026 — dukeofgaming — 2011-06-06T14:23:21+00:00

URL: https://externals.io/message/52990#53026 · In reply to: #53022

>
> 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?


>
> > […]
>
> 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

---

## #53031 — Sean Coates — 2011-06-06T15:15:29+00:00

URL: https://externals.io/message/52990#53031 · In reply to: #53026

> 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