rfc:objectarrayliterals

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
rfc:objectarrayliterals [2011/06/05 01:18] – created seanrfc:objectarrayliterals [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ===== RFC: First-Class Object and Array Literals ===== ===== RFC: First-Class Object and Array Literals =====
 +
 +  * Version: 1.0.3
 +  * Date: 2011-06-04 (Updated: 2011-06-06)
 +  * Author: Sean Coates <sean@php.net>
 +  * Status: Inactive
  
 ==== Introduction ==== ==== Introduction ====
Line 18: Line 23:
 This proposal calls for first-class JSON-like object and array literals This proposal calls for first-class JSON-like object and array literals
 (a.k.a. primitives, constructs) in PHP. (a.k.a. primitives, constructs) in PHP.
 +
 +This RFC supersedes the existing [[rfc:shortsyntaxforarrays|Short Syntax for Arrays RFC]].
  
  
Line 36: Line 43:
 Furthermore, JSON-proper is a serialization format, but this proposal Furthermore, JSON-proper is a serialization format, but this proposal
 concerns a declaratative, inline, interpreted object literal format. concerns a declaratative, inline, interpreted object literal format.
 +
 +In JSON-proper, keys must be quoted with ''"'' and not ''%%'%%''. This same behaviour should not be expected in PHP. Similarly, PHP arrays allow a trailing comma after the last element, but JSON does not allow this. The existing PHP behaviour should be allowed in these respects.
  
 Point of discussion (see below): the key-value separator will be both PHP's Point of discussion (see below): the key-value separator will be both PHP's
Line 43: Line 52:
 ==== Syntax Examples ==== ==== Syntax Examples ====
  
-<code>+<code php>
 <?php <?php
 // new syntax for simple arrays: // new syntax for simple arrays:
Line 95: Line 104:
 ?> ?>
 </code> </code>
 +
 +=== Interaction with third-party services that speak JS-literals ===
 +<code php>
 +<?php
 +// 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:
 +
 +$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
 +}'
 +*/
 +</code>
 +
 +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 this could have been written with the PHP definition of $esQuery in the proposed yet non-JSON compatible syntax (single quotes, for example), but it was written with double quotes because it is easier to pass off 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 it is expected that this syntax will be used both for interacting with third party services (as with ElasticSearch above), but also generally for object and array creation without a care about third parties.
 +
  
 ==== Benefits ==== ==== Benefits ====
Line 122: Line 187:
   * JavaScript (with which nearly all modern web apps must interface in some form) supports a very similar syntax. JavaScript (largely) supports a non-strict JSON implementation. The "JS" in JSON stands for JavaScript.   * JavaScript (with which nearly all modern web apps must interface in some form) supports a very similar syntax. JavaScript (largely) supports a non-strict JSON implementation. The "JS" in JSON stands for JavaScript.
   * Python supports a very similar syntax for defining lists and sets (which are somewhat analogous to PHP's arrays (non-associative)), and dictionaries, which are similar to PHP's associative arrays and anonymous (''StdClass'') objects.   * Python supports a very similar syntax for defining lists and sets (which are somewhat analogous to PHP's arrays (non-associative)), and dictionaries, which are similar to PHP's associative arrays and anonymous (''StdClass'') objects.
 +  * Ruby 1.9.1 added [[http://webonrails.com/2009/02/06/ruby-191-hash/|syntax improvements]] for its hashes to simplify the syntax and improve readability much like this RFC proposes.
  
  
Line 142: Line 208:
   * Performance concerns: encoding/re-encoding, memory usage.   * Performance concerns: encoding/re-encoding, memory usage.
  
 +==== Patch ====
 +  * A partial (arrays only, colons only) [[http://www.opendogs.org/pub/php-5.3dev-080109-sbar.patch|patch]] is available.
 +
 +==== Discussions ====
 +
 +  * [[http://marc.info/?t=130723757000001|[PHP-DEV] Object and Array Literals]]
  
 ==== Further Discussion Required ==== ==== Further Discussion Required ====
rfc/objectarrayliterals.1307236730.txt.gz · Last modified: 2017/09/22 13:28 (external edit)