Yes, I know. Then why are you and others demanding that the resulting syntax be fully compatible with JSON so it could be parsed by other JSON parsers? That makes no sense at all. A file with just ["foo"] in it won't be interpreted by PHP; you need at least <?php ?> wrappers and a semicolon, and then you can't just throw it at another JSON parser anymore.
There is absolutely no use case for this, but some people on this thread seem
to have some weird dream where they can somehow share code between languages or
whatever. Which they can't. Unless they want to start stripping or padding
stuff and generating code.
I was pointing out the encoding issue under the assumption that it somehow
*did* make sense, e.g. that you'd have a JSON compatible declaration somewhere
in a PHP file, extracted it with, say, a regex, and handed it to PHP's own JSON
parser, which might then struggle depending on the encoding of the file.
David
P.S. I guess that also answers Andrei's question regarding whether or not I
understood what a parser was or w/e :)
On 04.06.2011, at 02:43, John Crenshaw wrote:
> 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": "ä"}) is totally wrong
> in the first place, because json_decode requires a string, not an object.
>
> John Crenshaw
> Priacta, Inc.
>
> -----Original Message-----
> From: David Zülke [mailto:david.zue...@bitextender.com]
> 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('ä\u0123'), because json_decode() in
> PHP only accepts UTF-8 encoded input;
>
> Give it a shot:
>
> <?php
> $chr = "\xC3\xA4"; // "ä" as UTF-8
> var_dump(json_decode('["' . $chr . '\u00e4"]'));
> var_dump(json_decode('["' . utf8_decode($chr) . '\u00e4"]'));
> ?>
>
> That'll produce:
>
>> array(1) {
>> [0]=>
>> string(4) "ää"
>> }
>> NULL
>
> Understand what the problem is now?
>
> If someone does this in a latin1-encoded file:
>
> <?php $fancyNewArray = {"yay": "ä"}; ?>
>
> Then that is valid as a PHP array (as it's a latin1 "ä", so \xE4), but cannot
> be consumed by PHP's json_decode(). And that would be terribly inconsistent
> behavior.
>
> David
>
>
> On 02.06.2011, at 22:15, Andrei Zmievski wrote:
>
>> Stop spreading FUD, please.
>>
>> It's no different than writing json_decode("ä\u0123").
>>
>> 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.
>>
>> -Andrei
>>
>> On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
>> <david.zue...@bitextender.com> wrote:
>>> No we can't; I already explained why in another email last night. Copypasta:
>>>
>>> json_decode() can deal with Unicode sequences because decodes to UTF-8.
>>> That is not possible in a language construct:
>>>
>>> What if I do this, in a latin1 encoded file:
>>>
>>> $x = {foo: "ä", bar: "\u0123"}
>>>
>>> Should that then give mixed encodings? The "ä" in foo in latin1 and the
>>> stuff in bar in UTF-8?
>>>
>>> And what if I do:
>>>
>>> $x = {foo: "ä\u0123"}
>>>
>>> I'll either end up with an invalid UTF-8 sequence, or with latin1 character
>>> soup.
>>>
>>> David
>>>
>>>
>>> On 02.06.2011, at 18:04, Martin Scotta <martinsco...@gmail.com> wrote:
>>>
>>>> Could we first go out with fully JSON compatible version for 5.4?
>>>> and then later decide the => stuff based on how that worked.
>>>>
>>>> Native JSON is a big stuff for userland, and I'm pretty sure it will bring
>>>> a
>>>> hole of core version upgrades.
>>>>
>>>> Martin Scotta
>>>>
>>>>
>>>> On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates <s...@seancoates.com> wrote:
>>>>
>>>>>> 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
>>>>>
>>>>> I don't think anything is officially off the table, unless we forego
>>>>> discussion.
>>>>>
>>>>> 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 current
>>>>> PHP), and we interface with ElasticSearch. The paste I linked earlier is
>>>>> our
>>>>> primary ElasticSearch query.
>>>>>
>>>>> 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 and
>>>>> 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.
>>>>>
>>>>> 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 less
>>>>> abstracted, and a lot less prone to error.
>>>>>
>>>>> S
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>>>>
>>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
smime.p7s
Description: S/MIME cryptographic signature
