first of all thank you all for your answers. In my experience I tend to not write `var self = this;` or `var that = this;` since the introduction of bind. Last Aymeric example is indeed part of what I was asking ... developers like it because they don't have to write `.bind(context)` at the end neither `function` at the beginning plus the closure or scope might not be necessary. This is why I've asked if point 3 would be eventually faster ... but again there are few misunderstanding, specially from David. I'll try to reply inline.
On Wed, Oct 2, 2013 at 12:34 AM, David Bruant <bruan...@gmail.com> wrote: > Le 02/10/2013 04:35, Andrea Giammarchi a écrit : > > setTimeout accept extra arguments ... I write JavaScript that uses this >> feature. >> >> `setTimeout(callback, delay, arg1, arg2, argN, evenAnObject);` >> > What is "evenAnObject"? It doesn't look like a standard thing: > http://www.whatwg.org/specs/**web-apps/current-work/** > multipage/timers.html#**windowtimers<http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#windowtimers> `evenAnObject` is a way to solve the "frozen" state of passed arguments. For those non familiar, `setTimeout` and `setInterval` accepts extra arguments by W3C standard. http://www.w3.org/TR/2011/WD-html5-20110525/timers.html#timers This is working in every single ES3 JS engine you can try (even very old one) with the nice exception of IE < 10. However, this code will address exclusively those IE < 10 browsers and fix the behavior in there too. ```javascript /*@cc_on (function(f){ window.setTimeout =f(window.setTimeout); window.setInterval =f(window.setInterval); })(function(f){return function(c,t){var a=[].slice.call(arguments,2);return f(function(){c.apply(this,a)},t)}}); @*/ ``` IE10 and 11 won't execute such comment so you are good with a universal way to pass arguments. Some example: ```javascript function alertSum(a, b) { alert(a + b); } setTimeout(alertSum, 1000, 1, 2); ``` Above code will show 3 after a second. The problem David comes with variables ```javascript function alertSum(a, b) { alert(a + b); } var a = 1, b = 2; setTimeout(alertSum, 1000, a++, b++); ``` the result will be again 3 because arguments are "trapped by value" at `setTimeout` declaration. Accordingly David, to solve this problem you might want to pass an object and address its properties. ```javascript function alertSum(o) { alert(o.a + o.b); } var o = {a: 1, b: 2}; setTimeout(alertSum, 1000, o); o.a++; o.b++; ``` The result will be 5 so `evenAnObject` meant you can pass any kind of value, including an object that could be your context in the function through bind `setTimeout(fn.bind(ctx), 1000)` or extra argument `setTimeout(fn, 1000, ctx)` without needing to create both a timed execution and a new bound object but of course, fn should accept a pythonish `self` argument. I hope we are clear here ... the rest ... > > > >> so fat arrow does not solve much here, I can use self as first argument >> and I am good. >> >> `forEach` and all other arrays accept a second argument >> >> `array.forEach(doStuff, boundContextObject);` >> >> so fat arrow does not solve a thing in mostly all Array extras. >> > Both examples are most certainly design mistakes. It feels absurd that > every function accepting a function as argument must also have a second > argument for the |this| value (or even variable number of arguments to be > passed around). Especially in the ES5 era with Function.prototype.bind. > I wasn't talking about how great this approach is, I was rather saying that it is possible to send a context so design mistake or not, the fat arrow won't solve anything if not extra operations/oibjects to create promoting a "reuse nothing" pattern hopefully optimized better than current inline function, but something I've personally never advocated if operations are repeated. I create the `forEach` utility unscoped as much as possible and once per execution lifecycle, so that I can send the context through the second argument instead of create O(n) times the inline function or the fat arrow. > The design mistake is emphasized by the inconsistency in the order of > arguments in the 2 examples you provide. > I'm glad Node.js didn't make all async functions accept another argument > for |this|. > > > for **DOM** I use handlers as specified by **W3C** >> > Since when the DOM is specified by W3C? Must be about 10 years it isn't > the case anymore</troll> ;-) > Passing a function directly is standard too. Thanks for the enlightening troll, I was talking about a technique developers keep forgetting and ignoring, a technique described here which is **not a trick** just **standard behavior** http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener ```javascript AnyClass.prototype.handleEvent = function (e) { // will point to the element where // addEventListener was used e.currentTarget; // will be an instanceof AnyClass // the object passed as handler this[e.type](e); }; var handler = new AnyClass; handler.click = function (e) { this.clicked = true; // won't expando in the node alert([e.screenX, e.screenY]); }; document.body.addEventListener('click', handler); ``` Handler could be used for any sort of custom or real event and won't require any WeakMap to be attached and related to any DOM node. Once again, this is the best pattern for state-machine like DOM behavior and developers keep creating 234567890 bound functions instead forgetting that simply using a different approach they could both solve and speed up many things at once. This behavior is perfectly normalized in IE8 too, the only browser that does not have `addEventListener` and friends, through this ie8 library: https://github.com/WebReflection/ie8 Today, you could start writing a simplified and better approach to DOM <=> JS interactions. > > But "won't be able to remove later on" is false: > > document.addEventListener('**DOMContentLoaded', function dcl(){ > // whatev's > document.removeEventListener('**DOMContentLoaded', dcl); > }); You didn't use a fat arrow because indeed you cannot use one unless named and its name is available so ... what is your point here? The fat arrow will inevitably lead to patterns such: `document.addEventListener('eventName', (e) => e.stopPropagation());` where it's impossible to get rid of that later on if needed (remember the statemachine approach? I could redefine entire behaviors simply adding or removing a single object ... won't be possible with fat arrows all over) Even worst, that pattern could lead to this obscenity: ```javascript let fn; document.addEventListener('once', fn = (e) => e.currentTarget.removeEventListener(e.type, fn)); ``` WAIT, WHAT? Actually, we have a problem with the DOM. First of all the `this` will be the one at fat arrow function definition time, so that the node must be retrieved through `e.currentTarget` which means that every single framework that relies in `this` should be somehow updated if fat => arrow is desired. So, one of the major benefits of `addEventListener` compared with `attachEvent` is gone, `this` in the wild, most likely always `window` or `undefined` under `use strict` directive. So here my question: is fat arrow solving anything in this case? My answer is no. > > I understand that in some cases, specs allow to pass |this| or additional > arguments, but it doesn't make it a good idea. I see the fact that Node.js > didn't take that road as a very strong signal. > > David > node.js has been lucky enough to born in an era where `Function.prototype.bind()` was already there otherwise would have came up with a similar solution. That said, node.js also broke completely interoperability with any DOM Event we know since 1999 thanks to the (in?)famouse double argument pattern with the nullish error as first argument. Not everything chose there is good neither but I agree, it would have been ugly to put a final context argument to each class method. Best Regards
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
