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.
