I think what he was suggesting means the difference between setTimeout(foo.func, foo, 1000); and setTimeout(foo.func.bind(foo), 1000); which have pretty drastically different performance characteristics. That being said, compared to the overhead of setTimeout itself, or just about any async call, it's not that big of a deal, and is probably not needed.
On Sun, Jun 10, 2012 at 12:48 AM, Jorge <jo...@jorgechamorro.com> wrote: > On Jun 10, 2012, at 9:39 AM, Isaac Schlueter wrote: > > > > On Sun, Jun 10, 2012 at 12:20 AM, Jorge <jo...@jorgechamorro.com> wrote: > >> On Jun 8, 2012, at 8:06 PM, AJ ONeal wrote: > >> > >>> I would like to propose that an additional parameter, `context` be > added to core node modules that accept callbacks to give this-ness to the > callback. > >> > >> But don't call it context please the proper name is receiver. A context > in JS is much more than "this" :-P > >> > > I don't understand why: > > > > setTimeout(function (x, y, z) { > > // ... > > }, this, 1000) > > > > is better than: > > > > setTimeout(function (x, y, z) { > > // ... > > }.bind(this), 1000) > > > > The problem is that it puts `this` at the bottom of the function, > > instead of signaling it at the top when you enter the function > > visually. That's the problem ()=>{} addresses. If you don't like > > bind(), and can't wait for fat-arrow, > > But fat arrows don't let you choose the receiver, they simply bind "this" > lexically, and that's not always what you want. > > > then do `var me = this` and deal > > with it that way, or wrap your functions like: > > > > function foo (me) { return function () { > > me.doWhatever() > > }} > > > > setTimeout(foo(this), 1000) > > > > Sorry. It's a lovely suggestion, but we don't need this in core. The > > answer is no. > > Agreed. > -- > Jorge.