Live data from Hacker News

“This” in JavaScript

bjorn.tipling.com

91–99 of 99 posts

Re: “This” in JavaScript

#91
post #73
post #31

Earlier quoted context omitted.

Even more simply, I'd just say: 1) The keyword "this" refers to whatever is left of the dot at call-time. 2) If there's nothing to the left of the dot, then "this" is the root scope (e.g. Window). 3) A few functions change the behavior of "this"— bind , call and apply 4) The keyword "new" binds this to the object just created So if you're using the value of "this" in someFunction... thing.someFunction(); // this ===…

I see that some people are slowly redefining the word "simple" as applied to programming languages. A 4-point bullet list that still requires knowing about typical caller behavior is hardly "simple".

Actually, it's not about typical caller behavior. When you write a function, what 'this' is is going to depend on how your function is called. If you don't want caller behavior to affect your function, don't use 'this'. If you want to allow callers to choose what object your function should act on using a variety of convenient syntaxes, then write your function to use 'this', but be aware of all the ways a caller might set it.

Re: “This” in JavaScript

#92
post #62

Earlier quoted context omitted.

I agree it's a simple concept. But it's one of the weirdest thing in javascript, and I'd advise to forgo using 'this' in any situation that doesn't absolutely need it.

So basically most open source JS code out there is completely wrong?

I don't think a project is "wrong" if it is working. Also these a just opinions, but I think it's counterproductive.

I feel it's the same as class systems with inheritance and lots of OO properties implemented. It's not wrong, but it's so much overhead, so easy to shoot one's foot, for so few returns. And there's a class syntax coming to ES6, so I'm clearly in the minority.

For a discussion on the "this" use, there is an interesting talk[0] by D.Crockford on the subject, at about 8 min in (but I'd watch the whole thing). I don't agree with everything he is advising, but I think he has pretty compelling arguments overall.

There's a lot of things in js that are not necessary to write good code, and avoiding them can reduce a lot of the complexity IMO. Some people are OK with complexity and want expressivity, I'd prefer basic and predictable easily behaviours.

[0] https://www.youtube.com/watch?v=PSGEjv3Tqo0&noredirect=1

Re: “This” in JavaScript

#93

The author critically misunderstands the way that `this` gets set, and in doing so has developed a significantly overcomplicated mental model. This is exemplified in the statement: You can use this in any function on an object to refer to other properties on that object. This is not the same as an instance created with new. ... Note, there was no use of new , no Object.create and no function called to create obj. Thi…

It helped me immensely when I realized obj.method(); is a sugar for obj.method.call(obj); Similarly, this picture helped me understand `bind`: http://i.stack.imgur.com/StZOr.png The a-ha moment for JS is when you realize it's a way simpler language than you thought it was.

Yes - the trick with JS is to realize it has this functional core, and every object has an __proto__ property, and then most of its syntax is syntactic sugar over the top of that.

   new method()
is syntactic sugar for something like

   var _tmp = {};
   _tmp.__proto__ = method.prototype;
   _tmp.call(method);

Re: “This” in JavaScript

#94
post #85

Earlier quoted context omitted.

Does `setTimeout` have a default value for the time?

setTimeout with no timeout argument simply schedules the provided function for when the interpreter is next idle. Underscore.js wraps a similar unqualified call in _.defer (last i checked, anyway; they might now provide it with a very small number or 0 for the timeout). Edit: in both cases the result is the same in most browsers.

It's clamped to 4. You can't go lower than that.

There is `setImmediate` for making something run the very next cycle. However, only IE10+ supports it and the other browser vendors are against it. You can use abuse `postMessage` to get a similar effect.

Re: “This” in JavaScript

#95
post #66

Earlier quoted context omitted.

I'd say I use `this` outside of lexical context at least as much as I do within, and I rely on this's behaviour a lot when developing a DSL. It enables some rather elegant patterns, actually.

Patterns which could have been just as easily implemented using another more explicit technique for dynamic binding (like simply passing the dynamic parameter to the function as a normal argument) without fucking up the entire language design with invisible implicit magic, and dooming millions of programmers to repeatedly make difficult to detect, subtle mistakes, bugs and security holes. Please give me one example o…

Well, you could pass around the object but then you'd have to come up with a new object-literal syntax because `this` won't exist any more, unless you're planning on keeping it around but keeping it lexically scoped, in which case you have to stop using object literals as traits and prototypes.

At that point you might as well just redesign the language from scratch, which maybe you'd appreciate.

Guess I'm just not feeling the hate on this one.

Re: “This” in JavaScript

#96

Earlier quoted context omitted.

I agree. The fact that you have to write library code defensively to still work depending on how your method's call, or that you have to use an awkward bind to preserve the `this` context of a method is so annoying and error-prone to me.

Even when you remember to perform the awkward bind / Function.prototype.call / Function.prototype.apply / var self = this; you still may already be inside of another context where this is not correctly defined. So then your code LOOKS even more like it will work thanks to the cargo cult magic ceremonies you've performed perfectly, but in the wrong place. It's like going into the bathroom like you're supposed to, but…

I don't think that's how bind works. Can you give a code example that shows unintuitive behavior? What I'm hearing from you is something like:

    function foo() {
        var bar = function() {
            console.log(this);
        };
        return bar.bind(42);
    }

    foo().call(1337); // prints 42
...which behaves as expected, so I'm not sure what you're getting at?

Re: “This” in JavaScript

#97
post #31

The author critically misunderstands the way that `this` gets set, and in doing so has developed a significantly overcomplicated mental model. This is exemplified in the statement: You can use this in any function on an object to refer to other properties on that object. This is not the same as an instance created with new. ... Note, there was no use of new , no Object.create and no function called to create obj. Thi…

Even more simply, I'd just say: 1) The keyword "this" refers to whatever is left of the dot at call-time. 2) If there's nothing to the left of the dot, then "this" is the root scope (e.g. Window). 3) A few functions change the behavior of "this"— bind , call and apply 4) The keyword "new" binds this to the object just created So if you're using the value of "this" in someFunction... thing.someFunction(); // this ===…

Your comment inspired me to write a post on References in Javascript :) http://perfectionkills.com/know-thy-reference

Re: “This” in JavaScript

#99
post #46

The "this" keyword in JavaScript is a well-known anti-pattern. Although it can be explained with a few rules, it becomes cumbersome quickly. The anti-pattern around "this" is well-known for decades. For example, SICP explicitly mentions that anti-pattern. Of course, it doesn't refer to JavaScript, but to some other old programming language which had a keyword with very similar issues. I think it's not a hyperbole to…

As a side note, the relevant SICP lecture is 7B, second part, starting at 0:18:20.

https://www.youtube.com/watch?v=t5EI5fXX8K0&list=PLB63C06FAF...

Post reply on HN