Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52876 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74256 invoked from network); 4 Jun 2011 00:44:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jun 2011 00:44:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=johncrenshaw@priacta.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=johncrenshaw@priacta.com; 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:20806] helo=mx1.myoutlookonline.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 02/D1-08509-7DF79ED4 for ; Fri, 03 Jun 2011 20:44:08 -0400 Received: from st21.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id A4FC65534D5; Fri, 3 Jun 2011 20:44:04 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id E74545534CB; Fri, 3 Jun 2011 20:44:03 -0400 (EDT) Received: from MAILR001.mail.lan ([192.168.1.2]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Fri, 3 Jun 2011 20:43:07 -0400 To: =?iso-8859-1?Q?David_Z=FClke?= , Andrei Zmievski CC: Martin Scotta , Sean Coates , Anthony Ferrara , PHP internals Date: Fri, 3 Jun 2011 20:43:56 -0400 Thread-Topic: [PHP-DEV] RFC: Short syntax for Arrays (redux) Thread-Index: AcwiOy9ObuEidBYPQW29dRdHBLd7VgAFM47w Message-ID: References: <4DE5368A.6050603@moonspot.net> <8BEEEE49-8DA3-4634-BF9C-120F7A15B613@roshambo.org> <4C39B728-2283-49A7-87F5-B0CC9EC42505@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) This is a moot point. You wouldn't send that to json_decode. You would send= it to json_encode. In other words json_decode({"yay": "=E4"}) is totally w= rong in the first place, because json_decode requires a string, not an obje= ct. John Crenshaw Priacta, Inc. -----Original Message----- From: David Z=FClke [mailto:david.zuelke@bitextender.com]=20 Sent: Friday, June 03, 2011 6:11 PM To: Andrei Zmievski Cc: Martin Scotta; Sean Coates; Anthony Ferrara; PHP internals Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux) It's not FUD. It is different from writing json_decode('=E4\u0123'), because json_decode(= ) in PHP only accepts UTF-8 encoded input; Give it a shot: That'll produce: > array(1) { > [0]=3D> > string(4) "=E4=E4" > } > NULL Understand what the problem is now? If someone does this in a latin1-encoded file: Then that is valid as a PHP array (as it's a latin1 "=E4", so \xE4), but ca= nnot be consumed by PHP's json_decode(). And that would be terribly inconsi= stent behavior. David On 02.06.2011, at 22:15, Andrei Zmievski wrote: > Stop spreading FUD, please. >=20 > It's no different than writing json_decode("=E4\u0123"). >=20 > Your statement, "the stuff in bar in UTF-8" is wrong. The \u0123 > escape sequence is a representation of a Unicode character, not the > character itself. This representation can be encoded in any > ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it > directly in a Latin-1 encoded script is just fine. >=20 > -Andrei >=20 > On Thu, Jun 2, 2011 at 12:00 PM, David Z=FClke > wrote: >> No we can't; I already explained why in another email last night. Copypa= sta: >>=20 >> json_decode() can deal with Unicode sequences because decodes to UTF-8. = That is not possible in a language construct: >>=20 >> What if I do this, in a latin1 encoded file: >>=20 >> $x =3D {foo: "=E4", bar: "\u0123"} >>=20 >> Should that then give mixed encodings? The "=E4" in foo in latin1 and th= e stuff in bar in UTF-8? >>=20 >> And what if I do: >>=20 >> $x =3D {foo: "=E4\u0123"} >>=20 >> I'll either end up with an invalid UTF-8 sequence, or with latin1 charac= ter soup. >>=20 >> David >>=20 >>=20 >> On 02.06.2011, at 18:04, Martin Scotta wrote: >>=20 >>> Could we first go out with fully JSON compatible version for 5.4? >>> and then later decide the =3D> stuff based on how that worked. >>>=20 >>> Native JSON is a big stuff for userland, and I'm pretty sure it will br= ing a >>> hole of core version upgrades. >>>=20 >>> Martin Scotta >>>=20 >>>=20 >>> On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates wrote= : >>>=20 >>>>> Now, the only reason I would personally support the array shortcut is >>>>> if it was an implementation of JSON. I know that's not on the table >>>>> here >>>>=20 >>>> I don't think anything is officially off the table, unless we forego >>>> discussion. >>>>=20 >>>> My application is largely JSON-powered. We pass data from back- to >>>> front-end via JSON, we interact with MongoDB via the extension (which = is an >>>> altered JSON-like protocol (arrays instead of objects), but would be a= lot >>>> more fluent with actual objects-they're just too hard to make in curre= nt >>>> PHP), and we interface with ElasticSearch. The paste I linked earlier = is our >>>> primary ElasticSearch query. >>>>=20 >>>> The benefits of first-class JSON are important and wide-reaching; >>>> especially when interacting with systems like the ones I've mentioned. >>>> There's a huge amount of value in being able to copy JSON out of PHP a= nd >>>> into e.g. CURL to make a query to ElasticSearch without worrying that = I've >>>> accidentally nested one level too deep or shallow, or accidentally >>>> mistranslating my arrays into JSON. >>>>=20 >>>> This is not about saving five characters every time I type array(), it= 's >>>> about making my systems all work together in a way that's a little les= s >>>> abstracted, and a lot less prone to error. >>>>=20 >>>> S >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>>=20 >>>>=20 >>=20 >=20 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >=20 >=20