On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote:
> 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. > An implementation detail, don't nitpick. // Call a method of this object or class or whatever to make Andrea happy with my example var happies = sads.map(sad => this.makeAndreaHappy(sad)); That work for you? > > 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
