Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52835 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38844 invoked from network); 3 Jun 2011 07:38:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jun 2011 07:38:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=eloybote@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=eloybote@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: eloybote@gmail.com X-Host-Fingerprint: 209.85.160.42 mail-pw0-f42.google.com Received: from [209.85.160.42] ([209.85.160.42:38069] helo=mail-pw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AE/61-29906-57F88ED4 for ; Fri, 03 Jun 2011 03:38:31 -0400 Received: by pwj3 with SMTP id 3so931665pwj.29 for ; Fri, 03 Jun 2011 00:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CtBioiubZ5Nd1/muv01sITi51lekb+/iN10GRC+xPQo=; b=R4McLJkurZFtj03O1jKw5sbYRaW175ZdzS9ZSUU5Rzth6uWUJq8JEVD5s73/Ibg0S9 PEzPc7FdyKx6PB5rODKwNiGFzh7MEsT0HTQ8g6tYoxfdnhn3i0wqiJnEBQD2iQOaQpPD PjIK0u9jtEVS3Pf69zzYRRVsi9960Y1QCiRTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RnSgvxrnXosryDIRaLqHkhGoAzbpwPwcTMsm8ACV9cKyPzedus9ruMwcXhgTtSRHhi ixcCr7MuAW6pGhb+PpkLDmBmHB9j0jgwg/0RH9nIEw9tucLu8KGlOk+RwUf4QPWVDT8D Cnhhi9m23Bbmx3WrCNfY7GV4CETLwCUVGz4qA= MIME-Version: 1.0 Received: by 10.142.117.21 with SMTP id p21mr244022wfc.286.1307086707119; Fri, 03 Jun 2011 00:38:27 -0700 (PDT) Received: by 10.142.223.12 with HTTP; Fri, 3 Jun 2011 00:38:27 -0700 (PDT) In-Reply-To: References: <4DE5368A.6050603@moonspot.net> <8BEEEE49-8DA3-4634-BF9C-120F7A15B613@roshambo.org> <68339132.20110602001939@cypressintegrated.com> Date: Fri, 3 Jun 2011 09:38:27 +0200 Message-ID: To: John Crenshaw Cc: PHP internals Content-Type: multipart/alternative; boundary=001636e0a5a3de576804a4c9d683 Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux) From: eloybote@gmail.com (Eloy Bote Falcon) --001636e0a5a3de576804a4c9d683 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Oops, it was a mistake. I replied to all rather than to the list, so I apologize because I wanted to give my opinion in general and not to reply t= o anybody in particular. Regards. 2011/6/2 John Crenshaw > There=92s no need to be rude. If you can=92t make your point without atta= cking > people, then you need a better argument. > > > > =93JSON=94 in this case just means a simple object notation using {, [, a= nd :. > You know that. Yes, we=92re all abusing the term, just like we all abuse > =93AJAX=94, regardless of the fact that almost nobody ACTUALLY uses XML a= s the > transfer encoding. Who cares? =93JSON=94 is the best word available. Unle= ss you > can suggest a better word to differentiate this format from the others (o= ne > that isn=92t designed to insult anyone who disagrees with you) stop fussi= ng > about it. > > > > John Crenshaw > > Priacta, Inc. > > > > *From:* Eloy Bote Falcon [mailto:eloybote@gmail.com] > *Sent:* Thursday, June 02, 2011 3:58 AM > *To:* Sanford Whiteman > *Cc:* John Crenshaw; PHP internals > > *Subject:* Re: [PHP-DEV] RFC: Short syntax for Arrays (redux) > > > > > > 2011/6/2 Sanford Whiteman > > > > I don't think anyone cares about JSON for the sake of being perfect > > JSON, I didn't intend to give that impression. > > Then you should stop saying "pure JSON" and "true JSON" constantly! > > > > I'm only hoping for something that generally works on par with all > > the other JSON parsers in the world. > > OK, that trashes your example, where values were set based on the > result of a PHP function. There is no "par" for JSON parsers running > methods _at creation time_, within the server (author) context. > Setting vars to the return value of a function is something we take > for granted in real languages, but it cannot happen within what a > knowledgeable person would call "JSON." > > > > Yes, JSON is a very specific encoding, but when a developer writes > > something "jsony", what they mean is "an object/array with the > > following structure/values", because that is what the encoding > > really represents. > > Not Javascript developers. Maybe jQiddies think that > > {'$gt': strtotime('-1 day')} > > is "JSONy" more than it is "JS objecty"? > > This is like starting from "Wouldn't inline CSVs be great for creating > arrays?" and drifting to "I mean, not like with that comma-escaping > stuff, and, uh, newlines would be allowed in the middle of a record, > and you'd have to allow create-time interpolation of function calls. > You know, CSVy!" > > Only thing I might generously refer to as being "JSONy," while > provably not being valid JSON, is a string that conforms in every way > _except_ for using single quotes -- everywhere that doubles are > required -- instead of using doubles. Anything else is someone's > mangled "JankySON" or just not JSON. > > -- S. > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > -1 to the RFC. > > +1 to =3D> against : if the array short syntax it's finally implemented. > > > > I, being a lazy programmer, don't want anymore new syntax to do the same > thing. I don't care if it a) saves me houndred of kaystrokes in the > definition of arrays, or if b) it's more familiar with > _put_your_favorite_syntax_here_ because: > > > > a) I prefer the simple way of _this_ is done _this_ way against _this_ is > done _this_ way or _this_another_ way or _this_yet_another_ way. > > b) When another new fancy tendency of encoding appear I don't want to see > it in the core, because another one will appear in the future and then we > will be in the same point, stacking stuff forever or talking about > deprecating the old and breaking BC. > > > > My point is: I'm for implementing something that can't be done currently = in > PHP, but against for implementing another way of doing the same. > --001636e0a5a3de576804a4c9d683--