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
