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

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Sep 11 01:17:23 PDT 2014


nope, looks like you forgot (sad) parenthesis :P

My point was that Array extras have this second argument there to pass a
context and fat arrow, as opposite of the thin one, would make that
parameter misleading/confusing/pointless (same as bind would but fat makes
it easier to mistake the intent)

You know I wish thin arrow would have made it in ES6 as just exactly a
function shortcut as we know it since ever, "nothing to spec" if not its ->
syntax, much more use cases covered for all tastes.

Now I think we should (I will) leave this thread which intent is at this
point unclear :-)

Alex ... you can't really subclass Arrays without redefining slice, splice,
concat, and others behavior ending up loosing your initial "type" and I've
been writing sublcassing tricks since 2008

You can inject the proto but that's not really subclassing ... about tuning
performance, it's not just that, it's convenient to pass dictionaries,
maps, or parameters in there without binding because binding is indeed not
needed since the second argument is the context as specs say.

If you bind the callback ask yourself why is that ... you probably chose to
use half of the potential of the Array method for no reason.

Best Regards


On Thu, Sep 11, 2014 at 1:43 AM, Rick Waldron <waldron.rick at gmail.com>
wrote:

>
>
> 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/20140911/eb30cd07/attachment-0001.html>


More information about the es-discuss mailing list