Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:53063 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43282 invoked from network); 6 Jun 2011 18:05:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Jun 2011 18:05:14 -0000 Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain priacta.com designates 64.95.72.238 as permitted sender) X-PHP-List-Original-Sender: johncrenshaw@priacta.com X-Host-Fingerprint: 64.95.72.238 mx1.myoutlookonline.com Received: from [64.95.72.238] ([64.95.72.238:43212] helo=mx1.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 97/49-23189-5D61DED4 for ; Mon, 06 Jun 2011 14:05:11 -0400 Received: from st21.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 8DD77554725; Mon, 6 Jun 2011 14:05:06 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id B2AA9554732; Mon, 6 Jun 2011 14:05:05 -0400 (EDT) Received: from MAILR001.mail.lan ([192.168.1.2]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Mon, 6 Jun 2011 14:03:58 -0400 To: Andrei Zmievski , =?iso-8859-1?Q?David_Z=FClke?= CC: Martin Scotta , Sean Coates , Anthony Ferrara , PHP internals Date: Mon, 6 Jun 2011 14:03:58 -0400 Thread-Topic: [PHP-DEV] RFC: Short syntax for Arrays (redux) Thread-Index: Acwj/IiPhOfZ8XI2QUGIKCtCIZX+LgAbYVpw Message-ID: References: <4DE5368A.6050603@moonspot.net> <8BEEEE49-8DA3-4634-BF9C-120F7A15B613@roshambo.org> <4C39B728-2283-49A7-87F5-B0CC9EC42505@bitextender.com> <4723EA79-957B-4E03-85D1-F2F0E6DA29FA@bitextender.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: [PHP-DEV] RFC: Short syntax for Arrays (redux) From: johncrenshaw@priacta.com (John Crenshaw) On Sat, Jun 4, 2011 at 4:52 AM, David Z=FClke wrote: > Yes, I know. Then why are you and others demanding that the resulting syn= tax be fully compatible with JSON so it could be parsed by other JSON parse= rs? That makes no sense at all. A file with just ["foo"] in it won't be int= erpreted by PHP; you need at least wrappers and a semicolon, and t= hen you can't just throw it at another JSON parser anymore. I don't think anyone was asking for this. I and others have been misunderst= ood on this point, and there seems to be some confusion about how "other sy= stems" came into this discussion. The desire is to be able to copy/paste things back and forth and make it wo= rk with only minor tweaks. For example, when debugging a query against a sy= stem that uses JSON as the standard for communication, it is invaluable to = be able to copy the problem query from your code, paste it into whatever ad= ministrative interface you have, and replace any variable rvalues with cons= tants. After the problem has been worked out, you can copy from the admin i= nterface, paste back to the code, and restore any variables. If PHP handles= an object/array syntax that is roughly similar to JSON, this becomes easy.= The more different the syntaxes are, the more painful this becomes, until = eventually it really isn't an option at all (which is where we are now). An example perhaps more familiar to most of us is debugging complex regular= expressions. Imagine how impossible this would be if there were no way to = copy the regular expression from your code to a web based debugger without = rewriting it? Also, consider how frustrating it is sometimes when you paste= it back and it still doesn't work, because you forgot to escape your slash= es. The more manual translation the programmer has to do, the more impracti= cal these sorts of tools become for debugging. I know a lot of people on this list have strong feelings about whether othe= r systems should be using JSON as a query language/transfer encoding/whatev= er else; but, the fact is that they do. These systems are growing more popu= lar, and not going to disappear any time soon, which means that like it or = not, developers will need tools and languages that simplify the development= and debugging process. This RFC should be considered (among other things) = in terms of whether it is helpful to developers using these systems, but no= t in terms of whether anyone wishes these systems would go away (because th= ey won't). John Crenshaw Priacta, Inc.