(x) => {foo: bar}

[Isiah Meadows]

Once again...forgot to change the subject. (I get the digest...can't
you tell?) *sigh*

On Mon, Jan 5, 2015 at 11:48 PM, Isiah Meadows <impinball at gmail.com> wrote:
>> From: Marius Gundersen <gundersen at gmail.com>
>> To: Kevin Smith <zenparsing at gmail.com>, es-discuss <es-discuss at mozilla.org>
>> Cc:
>> Date: Mon, 5 Jan 2015 21:58:54 +0100
>> Subject: Re: (x) => {foo: bar}
>>
>> One scenario where arrow functions are likely to return objects is in the map function of arrays and the pipe function for streams. For example:
>>
>> [1,2,3]
>> .map(x => {value: x,  double:2*x})
>> .filter(x => x.double < 5)
>
> I guess, get ready to practice your Lispy parentheses-balancing skills? ;)
>
> ```js
> [1,2,3]
> .map(x => ({value: x,  double:2*x}))
> .filter(x => x.double < 5)
> ```
>
> ```clojurescript
> (filter
>     #(< (get % :double) 5)
>     (map (fn [x] {:value :x, :double :(* 2 x)})) [1, 2, 3])
> ```
>
> In all reality, it's easier to tell people to simply put parentheses
> around an object literal than to tell people to avoid very specific
> nits. The one ambiguity that would cause the most problems in parsing
> would be the property shorthand syntax: `{foo}`. This is technically
> both a valid block and object, so, given the right circumstances, that
> could rub against the halting problem, and would theoretically require
> up to the entire object to decide whether it is an object or block.
> So, something like this would require up to the function call to see
> it's an object and not a block (and not exactly obvious), and the
> result is never seen until runtime:
>
> ```js
> x => {x, y, z, f() {}}
> ```
>
> I'm skeptical on whether this will work on the implementation side.
>
>>
>> Marius Gundersen
>>
>> On 5 Jan 2015 21:16, "Kevin Smith" <zenparsing at gmail.com> wrote:
>>>
>>> Also, I did some analysis on this issue way back when.  In the codebases that I looked at the percentage of "bound this functions" which simply returned an object literal were quite low.
>>>
>>> (See the "%Object Literals" column)
>>>
>>> https://docs.google.com/spreadsheet/ccc?key=0Aro5yQ2fa01xdENxUzBuNXczb21vUWVUX0tyVmNKTUE#gid=0
>>> https://docs.google.com/spreadsheet/ccc?key=0Aro5yQ2fa01xdEJySWxhZ1VoZ0VaWTdldXp4NUtJd3c#gid=0
>>>
>>> (from https://esdiscuss.org/topic/btf-measurements)
>>>
>>> Of course, actually having arrow functions will change the situation to some degree, but the current tradeoff made sense in light of that evidence.
>>>
>>>
>>> On Mon, Jan 5, 2015 at 3:06 PM, Brendan Eich <brendan at mozilla.org> wrote:
>>>>
>>>> Kevin Smith wrote:
>>>>>
>>>>>
>>>>>     I think hacking around this would not get rid of the footgun, but
>>>>>     would just make it more complicated to understand the footgun,
>>>>>     personally.
>>>>>
>>>>>
>>>>> My gut reaction is to agree - the current rule, while it takes some trivial learning, is easy to understand and communicate and is reflected well in other parts of the language.  Also, additions to object literal syntax might make this more...weird:
>>>>>
>>>>>    x => { [abc](def = function() { huh() }) { blahblahblah } };
>>>>>
>>>>> "But it's an object literal, obviously!"
>>>>
>>>>
>>>> Yes, there's always a trade-off, some futures are foreclosed by syntax changes of this sort.
>>>>
>>>> Is it worth it? Hard to say, crystal ball service not answering the phone ;-). Still, the motivation for that strawman I wrote in 2011 lives on.
>>>>
>>>> /be
>>>
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>
> --
> Isiah Meadows



-- 
Isiah Meadows