On 02.06.2011, at 00:53, Marcel Esser wrote: > 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.
It's the worst idea of this decade, and just because others have repeated it,
it's not automatically a good one. {foo: 1, bar: 1} works fine, so they
implemented that, and then they realized that they had to do ORs as well, so
they invented $or and a whole bunch of other "workarounds".
> 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.
json_decode() decodes to UTF-8.
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
>
> - 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
>
>
smime.p7s
Description: S/MIME cryptographic signature
