... A community is writing the spec...

Rick Waldron waldron.rick at gmail.com
Wed Sep 10 10:58:52 PDT 2014


On Wed, Sep 10, 2014 at 8:17 AM, Alexandre Morgaut <Alexandre.Morgaut at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/ee9ed777/attachment.html>


More information about the es-discuss mailing list