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 <[email protected]> wrote: >> From: Marius Gundersen <[email protected]> >> To: Kevin Smith <[email protected]>, es-discuss <[email protected]> >> 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" <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> > > -- > Isiah Meadows -- Isiah Meadows _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
