Hacker News Reader

Comment by jQueryIsAwesome | Hacker News Reader

After assignment "self" does not change even if "this" does.

    var player = { 
        play: function(){
            var self = this;
            setTimeout(function(){
                console.log(self);
            });
        }
    }

View on HN

No but this is still bound at call time, so `self` will be foo in foo.play() just as this, so that's basically the same thing + a standard variable assignment to get the setTimeout working.

On a sidenote, I'm trying to get away from using self, and do object.bind in all my setTimeouts. To my mind, it leads to much cleaner code.

Bind is not supported in IE8 and older versions. You could use the underscore library or another one that haves a cross-browser bind method.

For my particular use case, IE8 is not an issue, but sure, a shim is like three lines, and we did use that before (when IE8 was an issue).

object.bind doesn't look very clean compared to using self.

And in JS is really easy to create an abstraction for this issue:

    function wait(o){
      return setTimeout(function(){ o.action.call(o.this) },o.delay*1000)
    }

To use it like this:

    wait({
       action : function(){ console.log(this) },
       delay : 1,       
       this : this
    });

If you're writing abstractions to avoid bad language features, maybe you shouldn't be using bad language features in the first place.

The nice thing about it is that it allows you to break out of nesting hell while still being prototyped... e.g. window.setTimeout(this.foo.bind(this), baz);

Since .bind is essentially currying, you could imaginably do window.setTimeout(this.foo.bind(this, bar), baz) as well, if foo is dependent on bar (timing out a request `bar' or something like that).

But you still have to be aware of the semantics of `this`:

    var play = player.play;
    play();

"self" will still strangely bind to "window" if not in strict mode.

Of course, taking the method out of the object will produce a different result. But if you are doing something weird like that you should know what you are doing.

I don't think it's _that_ weid considering JS is a language where functions are perfectly normal values. Someone unfamiliar with the semantics of "this" in JS might expect that:

    player[playing ? "play" : "pause"]()

(a not-so-weird JS pattern) would be the same as:

    (playing ? player.play : player.pause)()

In what other language you have direct access to methods as first class objects to do an immediate execution of a method returned by an execution container (parenthesis in JS) ?

I think most people would write it like this:

    playing ? player.play() : player.pause()

> In what other language you have direct access to methods as first class objects to do an immediate execution of a method returned by an execution container (parenthesis in JS) ?

Not sure if i understand the question. This seems to work in Python:

    s = "Hello"
    up = True
    (s.upper if up else s.lower)()

Not that it's a very pythonic piece of code, but it works, and i would expect many other languages support something similar.

Anyway, that's tangential. And i wasn't discussion what "most people would" do either. What i was trying to say is that by aliasing "var self = this" you're not automatically immune to the quirks of "this" in JS.

Indeed --- Python goes to great lengths to work this way, automatically binding the self argument on method extraction.

    o.f()

Can be decomposed in Python:

    func = o.f
    func()

JavaScript fails this test, and it's a shame.

It's actually a Javascript strength; one that makes it more dynamic.

    NodeList.prototype.map = Array.prototype.map

Just one line and now you can do stuff like:

    document.querySelectorAll("div").map(function(ele){
      return ele.id
    });

Ho, you beat me to it with the Python reference (see my other comment in this thread) :)

I don't know if it's really that bad that JS returns the unbound function when doing `obj.someFunc`, as it is consistent with any other property access: it returns the same thing that was assigned to that key in the object, or at some point in its prototype chain.

The really broken behavior, at least for me, is that when doing `var f = obj.someFunc(); f()`, the "this" gets bound to "window" in the f() call, instead of being null, or better yet raising an error whenever referenced, like an undefined variable.

Reply on news.ycombinator.com