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

Rick Waldron waldron.rick at gmail.com
Wed Sep 10 17:43:00 PDT 2014


On Wed, Sep 10, 2014 at 4:14 PM, Andrea Giammarchi <
andrea.giammarchi at 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.rick at gmail.com>
> wrote:
>
>>
>>
>> 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
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140910/846f436e/attachment.html>


More information about the es-discuss mailing list