4 ms·

The thing is, I don't think anyone is really getting confused about `this` in your simplistic call-site left-of-the-dot model. They get confused when they do ex

The thing is, I don't think anyone is really getting confused about `this` in your simplistic call-site left-of-the-dot model. They get confused when they do exactly the code I put, or similarly in a DOM event handler. And then there's weird cases, like calling bind on a bound function does nothing... If we what to talk about what we wish it looked like, I wish it was more like Rust, where left-of-the-dot is an implicit argument to an explicit parameter within the function.

spion 9y ago
That example is still explained by the simplistic model. You have a function function setTimeout(callback, delay) { do the set timeout thing, at the right time, call callback(); } You pass a function argument to it, but you're not calling that function, so you haven't passed the `this` argument: setTimeout(someObject.someFn, delay) From within setTimeout, the code gets that function and calls it without anything left of the dot callback(); So the `this` argument gets the default value in that environment (undefined/global/window) Calling bind on a bound function is also explained by the simplistic model: function bind(f, o) { return function(...args) { return o::f(...args) } } Once you partially apply the `this` argument you get a new function that calls the old function with the specified object as the `this` argument; that newly created function has its own implicit `this` argument, but it doesn't use it for anything, so it doesn't matter if you bind it. Prototypical inheritance is also explained by the simplistic model. You call a method: o.f() The method is not on the object, so its looked up in its prototype chain. Lets say its found after the 2nd prototype: [o.__proto__.f, o.__proto__.__proto__.f] Once found its called, but left of the dot is still the original object `o` so that is what is going to become the `this` argument. o::(o.__proto__.__proto__.f)() To me this is simpler than any other late binding explanation I've read, for any language, ever.
- jdmichal 9y ago
  So it's simplistic as long as you are capable of programming all these built ins with lower-level primitives... Which is not simple at all from the perspective of a beginner. I would think that once you get that far, `this` is probably not confusing anymore.
- nybble41 9y ago
  The confusing part for non-experts is that there are two "callable" types in JavaScript, functions and methods, but the language pretends that these two types are equivalent. Functions are self-contained and can be called without an object; methods depend on an implicit 'this' parameter. The fact that you can define and call a method using the syntax for a normal function call, without generating a type error, is a key part of the problem. The sequence "g = x.f; g()" should either be equivalent to "x.f()" or result in an error. Accepting both forms, but with subtly different behavior regarding implicit parameters, is bound to cause confusion. Note that in C++ there is a type-level distinction between pointers to ordinary functions (without 'this') and pointers to member functions, so the concepts expressed above are not without precedent in "real" languages. > To me this is simpler than any other late binding explanation I've read, for any language, ever. The object system in Lua achieves the same effect with much less complexity, IMHO. Methods in Lua are just ordinary functions which take an object as an explicit first parameter; there is no implicit 'this' argument. Lua objects are tables (associative arrays), with metatables providing a fallback for missing keys much like JavaScript's prototype chain. The dot syntax (x.f) is nothing more than syntactic sugar for the table lookup x['f']. To call methods idiomatically you use the colon operator x:f(...), which is equivalent to x.f(x, ...) except that x is only evaluated once. Like JavaScript, Lua is dynamically typed, with missing arguments defaulting to nil, so you won't get a clean type error if you forget to pass the first parameter. However, there is no hidden, context-sensitive 'this' to worry about, and if you pass an argument fn=x.f to a function which calls it as fn(...) then the arguments will be exactly the same as if you had written x.f(...) directly—most likely not what you intended, but it is at least apparent why it failed.
  - spion 9y ago
    No, there aren't two callable types in JavaScript. Thats precisely the point. Every single function has a `this` argument: function f() { return this + 5; } But there are only two ways to call it: f.call(5) // calls with `this` argument set to 5 and let x = new Number(5) x.f = f; x.f(); // syntax sugar for to x.f.call(x) The confusing part here is that `x.f()` is very different from `x.f`, and is most definitely NOT the same as `(x.f)()`, but more of an `(x.f).call(x)` Other than that and the fact that the argument is always there even if you don't specify it, its exactly the same as Lua, metatables (prototypes) and all. To resolve this confusion once and for all, we desperately need the bind operator [1] to provide a primitive on top of which the rest can be explained. [1]: https://github.com/tc39/proposal-bind-operator https://github.com/tc39/proposal-bind-operator
carussell 9y ago
> They get confused when they do exactly the code I put, or similarly in a DOM event handler. Well, they're trying to operate on some thing, but they're not passing in that thing to operate on. (And usually while telling themselves that this jibes with FP, for some reason.) In fact, they're trying really hard to avoid explicitly passing in the thing they want to do something with. And they still want it to work the right way. Are the expectations reasonable?

spion 9y ago

That example is still explained by the simplistic model. You have a function function setTimeout(callback, delay) { do the set timeout thing, at the right time, call callback(); } You pass a function argument to it, but you're not calling that function, so you haven't passed the `this` argument: setTimeout(someObject.someFn, delay) From within setTimeout, the code gets that function and calls it without anything left of the dot callback(); So the `this` argument gets the default value in that environment (undefined/global/window) Calling bind on a bound function is also explained by the simplistic model: function bind(f, o) { return function(...args) { return o::f(...args) } } Once you partially apply the `this` argument you get a new function that calls the old function with the specified object as the `this` argument; that newly created function has its own implicit `this` argument, but it doesn't use it for anything, so it doesn't matter if you bind it. Prototypical inheritance is also explained by the simplistic model. You call a method: o.f() The method is not on the object, so its looked up in its prototype chain. Lets say its found after the 2nd prototype: [o.__proto__.f, o.__proto__.__proto__.f] Once found its called, but left of the dot is still the original object `o` so that is what is going to become the `this` argument. o::(o.__proto__.__proto__.f)() To me this is simpler than any other late binding explanation I've read, for any language, ever.

jdmichal 9y ago
So it's simplistic as long as you are capable of programming all these built ins with lower-level primitives... Which is not simple at all from the perspective of a beginner. I would think that once you get that far, `this` is probably not confusing anymore.
nybble41 9y ago
The confusing part for non-experts is that there are two "callable" types in JavaScript, functions and methods, but the language pretends that these two types are equivalent. Functions are self-contained and can be called without an object; methods depend on an implicit 'this' parameter. The fact that you can define and call a method using the syntax for a normal function call, without generating a type error, is a key part of the problem. The sequence "g = x.f; g()" should either be equivalent to "x.f()" or result in an error. Accepting both forms, but with subtly different behavior regarding implicit parameters, is bound to cause confusion. Note that in C++ there is a type-level distinction between pointers to ordinary functions (without 'this') and pointers to member functions, so the concepts expressed above are not without precedent in "real" languages. > To me this is simpler than any other late binding explanation I've read, for any language, ever. The object system in Lua achieves the same effect with much less complexity, IMHO. Methods in Lua are just ordinary functions which take an object as an explicit first parameter; there is no implicit 'this' argument. Lua objects are tables (associative arrays), with metatables providing a fallback for missing keys much like JavaScript's prototype chain. The dot syntax (x.f) is nothing more than syntactic sugar for the table lookup x['f']. To call methods idiomatically you use the colon operator x:f(...), which is equivalent to x.f(x, ...) except that x is only evaluated once. Like JavaScript, Lua is dynamically typed, with missing arguments defaulting to nil, so you won't get a clean type error if you forget to pass the first parameter. However, there is no hidden, context-sensitive 'this' to worry about, and if you pass an argument fn=x.f to a function which calls it as fn(...) then the arguments will be exactly the same as if you had written x.f(...) directly—most likely not what you intended, but it is at least apparent why it failed.
- spion 9y ago
  No, there aren't two callable types in JavaScript. Thats precisely the point. Every single function has a `this` argument: function f() { return this + 5; } But there are only two ways to call it: f.call(5) // calls with `this` argument set to 5 and let x = new Number(5) x.f = f; x.f(); // syntax sugar for to x.f.call(x) The confusing part here is that `x.f()` is very different from `x.f`, and is most definitely NOT the same as `(x.f)()`, but more of an `(x.f).call(x)` Other than that and the fact that the argument is always there even if you don't specify it, its exactly the same as Lua, metatables (prototypes) and all. To resolve this confusion once and for all, we desperately need the bind operator [1] to provide a primitive on top of which the rest can be explained. [1]: https://github.com/tc39/proposal-bind-operator https://github.com/tc39/proposal-bind-operator

carussell 9y ago

> They get confused when they do exactly the code I put, or similarly in a DOM event handler. Well, they're trying to operate on some thing, but they're not passing in that thing to operate on. (And usually while telling themselves that this jibes with FP, for some reason.) In fact, they're trying really hard to avoid explicitly passing in the thing they want to do something with. And they still want it to work the right way. Are the expectations reasonable?