Hrm. It seems to me that it's not just Mongo that has chosen that as a
query definition language. A fair number of other projects have, too. If
not as a query language, then related things.
As for decoding Unicode, well, json_decode seems to do a pretty good job.
And if I am not mistaken, they are always in quotation marks, so it
shouldn't really be such a terrible issue to delimit as such. I am not
certain about that, but, again, json_decode seems to manage.
- M.
--
Marcel Esser
Vice President of Engineering, CROSCON
+1 (202) 470-6090
marcel.es...@croscon.com
Before printing this e-mail, please consider the rainforest.
On 6/1/11 6:47 PM, "David Zülke" <david.zue...@bitextender.com> wrote:
>Just because the MongoDB developers were stupid enough to build a query
>language on top of JSON does not mean that JSON or JavaScript object
>literals need to be supported in PHP. And it wouldn't be possible anyway
>since JSON allows Unicode escape sequences, and PHP cannot even represent
>those as it is not aware of runtime encodings.
>
>Besides, outside the use case of json_decode(), stdClass is rarely ever
>useful, so I don't understand why we're even discussing {} shorthands
>here. It's not in the RFC either, so good job on focusing on the issue
>and not diluting the discussion.
>
>Getting back to the RFC: I think it's problematic to have two separate
>syntaxes for the key/value separator. For consistency's sake, I'd rather
>just have "=>" but not ":". Just my $0.02.
>
>David
>
>
>On 02.06.2011, at 00:09, John Crenshaw wrote:
>
>> For small linear arrays, neither format is "more readable" but for even
>>mildly complex structures, there is a clear difference. Consider the
>>following Mongo query:
>>
>> $query = array(
>> 'time'=>array('$and'=>array(
>> array('$gt'=>strtotime('-1 day')),
>> array('$lt'=>time()),
>> )),
>> '$or'=>array(
>> array('foo'=>'bar'),
>> array('hello'=>'world')
>> )
>> );
>>
>> Vs. the JSON form:
>> $query = {
>> time: {'$and': [
>> {'$gt': strtotime('-1 day')},
>> {'$lt': time()},
>> ]},
>> '$or': [
>> {foo: 'bar'},
>> {hello: 'world'}
>> ]
>> };
>>
>> Because of the clear readability difference I'll take anything, but
>>JSON would be much better than just an "array shorthand".
>>
>> John Crenshaw
>> Priacta, Inc.
>>
>> -----Original Message-----
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Wednesday, June 01, 2011 5:18 PM
>> To: PHP internals
>> Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
>>
>> Personally, I think focusing on a character savings is the wrong
>> reason to take on any problem. I don't care how long it takes for me
>> to type code. I don't care how much extra hdd space it takes. But
>> what I do care about is how readable it is.
>>
>> To me, the array shortcut syntax is pointless. Do you really mean to
>> tell me that `[1, 2]` is more readable/easier to understand than
>> `array(1,2)`? To me, it's about a wash.
>>
>> However, the object shortcut syntax is a major win. For example:
>>
>> $person = new stdClass();
>> $person->city = 'ogden';
>> $person->state = 'ut';
>> $perspn->country = 'usa';
>> $person->favoriteNumbers = array(4, 12, 37, 42);
>> $person->somethingWithNumbers();
>> $person->unluckyNumbers = array(6, 13, 21);
>> $person->likesPhp = 'very much so';
>>
>> vs
>>
>> $person = { 'name' => 'Justin',
>> 'city' => 'ogden',
>> 'state' => 'ut',
>> 'country' => 'usa',
>> 'favoriteNumbers' => [ 4, 12, 37, 42],
>> 'unluckyNumbers' => [ 6, 13, 21],
>> 'likesPhp' => 'very much so'
>> }
>>
>> Did you notice what happened there? There's two differences. Try to
>> find them. Neither would be possible with the shortcut syntax.
>>
>> 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, but that's the only benefit I can see to implementing a shortcut
>> for arrays (that would save 5 characters per instance).
>>
>> Just my $0.02...
>>
>> Anthony
>>
>> On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony
>><jus...@justincarmony.com> wrote:
>>> To address the soapbox:
>>>
>>> Its not just to reduce the five characters at the beginning, but when
>>>you have more complex structures as well. There was already a great
>>>example shown
>>>(http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html)
>>>of that. Also, if object support is added (which we need to add to the
>>>RFC), you can cut down on a lot more verbose code, especially with
>>>objects.
>>>
>>> $person = { 'name' => 'Justin',
>>> 'city' => 'ogden',
>>> 'state' => 'ut',
>>> 'country' => 'usa',
>>> 'favoriteNumbers' => [ 4, 12, 37, 42],
>>> 'unluckyNumbers' => [ 6, 13, 21],
>>> 'likesPhp' => 'very much so'
>>> };
>>>
>>> Characters: 192
>>>
>>> Current way:
>>>
>>> $person = new stdClass();
>>> $person->city = 'ogden';
>>> $person->state = 'ut';
>>> $person->country = 'usa';
>>> $person->favoriteNumbers = array(4, 12, 37, 42);
>>> $person->unluckyNumbers = array(6, 13, 21);
>>> $person->likesPhp = 'very much so';
>>>
>>> Characters: 229
>>>
>>> That is a 37 character difference. But the real driving factor is
>>>given PHP's lack of named parameter syntax, passing objects and arrays
>>>(or sometimes a mix, depending on the framework) is becoming very
>>>popular. So not only do you save some typing just once, but if you use
>>>this pattern a lot, you save a lot of typing over your entire project.
>>>Also, when dealing with objects, I have to make sure I retype "person"
>>>correctly each time. If I don't, I'll get a notice error. But with the
>>>new syntax, it'll throw a parsing error so I can know a lot quicker
>>>what my issue is.
>>>
>>> As for syntax highlighters, IDEs, books, etc all being outdated, first
>>>off no one is suggesting to deprecate the array() function. So you will
>>>only use this new syntax if you choose to do so. Second, we broke
>>>syntax highlighters, IDEs, and so forth when we introduced namespaces,
>>>and every IDE and syntax highlighter I used updated very quickly to
>>>support them. I'm assuming the IDEs spent a great deal more time adding
>>>Namespacing support than it will to support a short syntax for arrays
>>>and objects.
>>>
>>> PHP has made short syntax for other things, such a if statement short
>>>codes. Yet many books don't cover it, since it is one of those things
>>>you read in the documentation later and decide "Do I want to use this?"
>>>No one is forcing anyone to use (1 == 1 ? true : false) type of if/then
>>>logic. The same will work with the new syntax.
>>>
>>> My two cents.
>>>
>>> Justin
>>>
>>> On Jun 1, 2011, at 2:37 PM, Michael Shadle wrote:
>>>
>>>> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye <pierre....@gmail.com>
>>>>wrote:
>>>>
>>>>> I modified the vote page, pls move your votes to the desired syntax
>>>>> (or global -1)
>>>>
>>>> This is a good idea to group things like this.
>>>>
>>>> Back on the soapbox. All of this is just to reduce typing "array" (5
>>>> characters) before things?
>>>>
>>>> Old:
>>>> $foo = array('a' => 'b', 'c' => 'd');
>>>>
>>>> More than likely new:
>>>> $foo = ['a' => 'b', 'c' => 'd'];
>>>>
>>>> 5 character difference for each array being saved. That's it. At the
>>>> expense of syntax highlighters, IDEs, books, all becoming outdated and
>>>> need to be updated. For a language construct that has been around for
>>>> what, 10 years?
>>>>
>>>> Oh, and for anyone desiring a ":" for this new shorthand, why stop at
>>>> array shorthand. Why not change this from:
>>>> foreach($foo as $key => $val)
>>>>
>>>> To:
>>>> foreach($foo as $key: $val)
>>>>
>>>> That would save one character for each array iteration like that.
>>>>
>>>> Also - if we're worried about saving characters and shorthand why not
>>>> just remove the "$" language construct? That's a LOT of keystrokes. In
>>>> my WordPress install, that's 75,412 characters saved. Versus 6,960
>>>> "array(" matches, which would save 34,800 characters.
>>>>
>>>> These were quick examples from a coworker. Just another PHP user who
>>>> said "wait why would they make another way to express an array?"
>>>>
>>>> --
>>>> 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
>>
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
