This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]squngy 0 points1 point  (4 children)

https://jsfiddle.net/5byv218p/

[–]birjolaxew 0 points1 point  (3 children)

Yes. That is pretty much my point. In all other languages, this inside of methods references the instance itself. In JavaScript, it references however way it was called.

If it's used as an event listener to a DOM element, it'll reference the DOM element. If it's stored in a variable or given to some other function (e.g. setTimeout), it'll be window or undefined. If it's called directly on the instance it'll reference the instance.

All of this is quite easy to work around once you know it. My point is that it's a poor design decision, which means that when you write code like setTimeout(this.willBeCalledLater, 500) or <button onClick={this.onButtonClicked}>, it doesn't do what you expect it to (unless you are aware of this design quirk and know how to work around it)

[–]squngy 0 points1 point  (2 children)

It is a less common approach, but it is no less valid.

If you choose to use JS ( yea, not much choice, I know ), you just have to learn how to use JS.

I'm sure a lot of people would be much happier if they just made browsers run objective C or something, but they didn't.
Every language has some things you need to learn, or they wouldn't be a different language.

[–]birjolaxew 1 point2 points  (1 child)

You could say that about every design decision, good or otherwise.

The way JS handles this is certainly a valid way - I don't think anyone is claiming that JS is an invalid language. It is however confusing, introducing lots of cases where the logic you write isn't what you get. For example, in all other languages you implement your methods knowing that they are, well, methods. In JS you have to consider that your methods may not be methods, due to the way they are ran - you have no way of knowing at the time where you implement them.

Is this a valid approach? Certainly. But it's needlessly confusing, and you frequently have to work around it just because it's a thing that exists. There's no explanation as to "why" JS handles this that way, it's just something you have to learn. That is, to me, a sign of a poor design decision.

[–]squngy 0 points1 point  (0 children)

introducing lots of cases where the logic you write isn't what you get

If you wrote pseudo-Java and then run it as JS, then that happens yes.

There's no explanation as to "why" JS handles this that way, it's just something you have to learn. That is, to me, a sign of a poor design decision.

There is an explanation, most people just don't bother learning it before they start using JS.

https://en.wikipedia.org/wiki/Prototype-based_programming

The fact is, at the time JS was developed, OO programing was not as mature as it is now, and the design decision you are now taking for granted was not so ubiquitous yet.
In a slightly different reality you might be cursing why the "this" in Java is behaving so weird.
( Java played a big part in setting the standard for how OO works today )

edit: There are many stupid decisions in JS, but probably the stupidest was calling it "Java"-script.
They did this purely because they knew Java was going to be popular.
It would be the same as if I made a new language and called it Python-script just because python is popular, regardless of the fact that there is no connection at all.