with all due respect Rick, and you know we've been talking about this already, your forEach => example assumes you have created a subclassed Array ... which trust me, it's the least common case you gonna have in the real world 'cause basically impossible before ES6.
Everybody else that used to pass a different context to do something more meaningful would fall in that trap at least once. Of course they will learn "their" mistakes ... but please don't use forEach as example about how cool is fat arrow 'cause in my opinion, with Array extras, that's actually a perfect place where fat arrows is the most confusing. Regards On Wed, Sep 10, 2014 at 6:58 PM, Rick Waldron <waldron.r...@gmail.com> wrote: > > > On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut < > alexandre.morg...@4d.com> wrote: > >> Hi, >> >> The way this discussion started looked very troll oriented, but let >> comment few things I more or less agree or not with >> >> >> >> What I see is more functionality of the browser api then an actually >> language. >> >> >> I actually work for 4D that provide JavaScript on the server in its >> Wakanda Server which is not using node.js (at least for now) >> I have to disagree with this statement as I see very good added value in >> ES6 for our developers on server-side >> >> >> >> >> And I look into node promise and the spec promise on MDN... And I'm still >> not seeing the big picture. Could you give me a brief in your own words.... >> >> >> I think the first place I saw Promise as a specification for JavaScript >> was on the CommonJS mailing list and wiki >> http://wiki.commonjs.org/wiki/Promises >> >> Then on WHATWG, first called Future (not anymore online) and via this >> github repository >> https://github.com/slightlyoff/Promises/tree/master/historical_interest >> >> Then in W3C drafts >> http://www.w3.org/TR/2013/WD-dom-20131107/#promises >> http://heycam.github.io/webidl/#idl-promise >> >> Before finally going into JS core, then in ECMAScript >> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects >> >> An interesting blog post about Promise history in JS: >> https://infrequently.org/2013/06/sfuturepromiseg/ >> >> It intends to make life better when chaining async callback calls which >> is absolutely not browser specific >> It may have stay as a library, but then no Specification call rely on it, >> and many actually upcoming HTML5 features choose to rely on it >> >> >> >> >> And this stupid ()=>{} arrow function... After seeing this I got the >> ideal of letting functions follow the same rules as for, if, while... That >> if it's one line of code, than let it be: >> function add(arg0) console.log(arg++); >> >> With out a body --curly braces--... Funny thing is that Firefox allow >> this syntax style. >> >> var arr = []; >> [0,1,2,3].forEach(function(arg0)arr.push(100+arg0)); >> arr; >> >> Copy & paste in Firefox to see. >> >> >> I'm not big fan neither of fat arrow functions because: >> - the code looks less expressive to me, code becomes very cryptic for >> anyone that don't know them and confusing as potentially associated to >> "+=", "*=", ... >> > > There is nothing ambiguous about `=>` with regard to existing compound > assignment operators. > > >> - they have no room for a function name that would be useful in debugger >> stacks and closure scope names, or profilers function call counts >> >> Still beware those are not only about syntax but also have different >> behaviors. The binding of "this" is different >> I admit I fear more confusion when I see people choosing the Array >> forEach() to show an example >> By default "this" in the forEach callback is bound to its second >> parameter, so some developers may have some surprises >> > > No, the default `this` in forEach is undefined. An explicit `thisArg` can > be provided as a second arg. In the most common case, fat arrow simplifies. > > items.forEach(function(item, i) { > this[i] = doSomeComputingOnItem(item); > }, this); > > // with or without the braces, it doesn't matter. > items.forEach((item, i) => { > this[i] = doSomeComputingOnItem(item); > }); > > > Any attempt to do: > > // with or without the braces, it doesn't matter. > items.forEach((item, i) => { > this[i] = doSomeComputingOnItem(item); > }, this); > > > Will just work because it means the same thing (even though the explicit > `thisArg` is just ignored). > > But mistakes like the following will be discovered very quickly and it's a > mistake developers will likely only make once (if ever). > > // with or without the braces, it doesn't matter. > items.forEach((item, i) => { > this[i] = doSomeComputingOnItem(item); > }, someOtherObject); > > > > >> >> >> >> And the generator function... Couldn't it have been: generator(args){ >> yield args += "gen"; >> console.log(args); >> } >> >> Plus with a constructor: >> new Generator(); >> >> >> This is a little different story >> Using non reserved keywords will for sure break some existing code >> But of course another more explicit option could have been to provide a >> new method on the Function native object >> ex: Function.generator() >> > > What exactly does that do? If it's just a regular function, then how could > `yield` have been safely made into a keyword within the body? > > > Rick > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
