Amongst other things, the bind operator is very useful for React, so instead of having to call this.handleChange.bind(this) you can just call ::this.handlechange . As in, you can type this: . It's a minor thing, but I prefer it a lot more than the explicit bind syntax. There are other cases as well, but since I'm doing a lot of work in React at the moment, having that is really convenient.
ECMAScript bind operator proposal
41–50 of 50 posts
Re: ECMAScript bind operator proposal
#42The "this" keyword in JS has very bad characteristics and is full of traps. I really wish we could stop building on top of this abomination (fake ES6 classes, binding, etc) The |> operator (chaining of regular functions) would be so much better to program with. We don't need both. https://github.com/mindeavor/es-pipeline-operator
At one point I had memorized the corner cases* of `this` for the pointless reason of stumping people who thought they knew it. The only thing it really taught me was to avoid it.
*My favorite is "what does `this` point to when running `eval()`"? The current context. "What if you assign `eval` to a variable and then use that?" The global context.
Re: ECMAScript bind operator proposal
#43Earlier quoted context omitted.
It's a pipe dream though. I mean, I wish an omnipotent, omni-benevolent dictator would force everyone to stop using `this` and refactor it out of all existing code as much as the next guy, but until that happens, the best path forward is to pave the cow paths and make the ugly parts easier to deal with.
Its just not taught correctly. `this` is the hidden function argument passed by putting it left of the dot; from that, everything else follows.
Which is, of course, the same way `this` or `self` works in virtually every OO language.
I honestly thought this was common knowledge, and not that hard to grasp. How else is `this` being taught?
Re: ECMAScript bind operator proposal
#44Earlier quoted context omitted.
Its just not taught correctly. `this` is the hidden function argument passed by putting it left of the dot; from that, everything else follows.
Which is, of course, the same way `this` or `self` works in virtually every OO language. I honestly thought this was common knowledge, and not that hard to grasp. How else is `this` being taught?
The difference is the JS has late binding.
myObj.myMethod();
var x = myObj.myMethod;
x();
myList.map(myObj.myMethod);
Re: ECMAScript bind operator proposal
#45Earlier quoted context omitted.
Which is, of course, the same way `this` or `self` works in virtually every OO language. I honestly thought this was common knowledge, and not that hard to grasp. How else is `this` being taught?
The difference is the JS has late binding. myObj.myMethod(); Has different semantics than var x = myObj.myMethod; x(); Which causes code like: myList.map(myObj.myMethod); to behave somewhat unintuitively.
Your examples don't need late binding to have different semantics — dynamic dispatch will suffice. That's not different from any other OO language (except perhaps in C++ for non-virtual methods). That's how we get polymorphism out of subtypes, after all: methods are resolved based on the dynamic value of the receiver at runtime, yielding single dynamic dispatch. Regardless of language, the `this` or `self` reference within a method always semantically behaves as if it were an additional parameter (except in typed languages where the variance under the subtyping relation is reversed, iirc), and is often implemented as such, albeit usually implicitly.
Of course, late binding implies dynamic dispatch, but the reverse isn't true. On the other hand, almost every untyped OO language uses late binding (I can't even think of one that doesn't, off the top of my head...), as do some typed languages (those that target the .NET CLR, for example), so even with your stronger assertion JS far from unique in that regard.
That behavior is standard fare for OO. If anyone finds it tricky, I find it more likely that the struggling programmer has yet to internalize OO than that JS is doing something strange (in this particular case, I mean... JS does plenty of strange shit otherwise ;) ).
Re: ECMAScript bind operator proposal
#46Earlier quoted context omitted.
The difference is the JS has late binding. myObj.myMethod(); Has different semantics than var x = myObj.myMethod; x(); Which causes code like: myList.map(myObj.myMethod); to behave somewhat unintuitively.
Your examples don't need late binding to have different semantics — dynamic dispatch will suffice. That's not different from any other OO language (except perhaps in C++ for non-virtual methods ). That's how we get polymorphism out of subtypes, after all: methods are resolved based on the dynamic value of the receiver at runtime, yielding single dynamic dispatch. Regardless of language, the `this` or `self` reference…
The difference is that JS has no binding, yet it still allows for first class methods. Thus the OO "illusion" (object owns the methods) is broken: there are no methods, just functions that take an argument named `this`, in a slightly weird way, only when attached to records.
Re: ECMAScript bind operator proposal
#47Earlier quoted context omitted.
Your examples don't need late binding to have different semantics — dynamic dispatch will suffice. That's not different from any other OO language (except perhaps in C++ for non-virtual methods ). That's how we get polymorphism out of subtypes, after all: methods are resolved based on the dynamic value of the receiver at runtime, yielding single dynamic dispatch. Regardless of language, the `this` or `self` reference…
The difference is that JS has no binding, yet it still allows for first class methods. Thus the OO "illusion" (object owns the methods) is broken: there are no methods, just functions that take an argument named `this`, in a slightly weird way, only when attached to records.
> The difference is that JS has no binding ... just functions that take an argument named `this`
Associating a name with a value is precisely what binding is.
Frankly, though, I don't understand this comment at all. Care to clarify for me?
Re: ECMAScript bind operator proposal
#48Earlier quoted context omitted.
The difference is that JS has no binding, yet it still allows for first class methods. Thus the OO "illusion" (object owns the methods) is broken: there are no methods, just functions that take an argument named `this`, in a slightly weird way, only when attached to records.
> The difference is that JS has no binding ... just functions that take an argument named `this` Associating a name with a value is precisely what binding is. Frankly, though, I don't understand this comment at all . Care to clarify for me?
In Python
b = foo.bar
b()
let b = foo.bar.bind(foo)
Re: ECMAScript bind operator proposal
#49Earlier quoted context omitted.
Its just not taught correctly. `this` is the hidden function argument passed by putting it left of the dot; from that, everything else follows.
Which is, of course, the same way `this` or `self` works in virtually every OO language. I honestly thought this was common knowledge, and not that hard to grasp. How else is `this` being taught?
> I honestly thought this was common knowledge
For whatever reason it isn't common knowledge in JS-land.
> How else is `this` being taught?
Sadly it very seldom is taught this way. It tends to be a realization people come to after using the language for a while [1].
Re: ECMAScript bind operator proposal
#50Earlier quoted context omitted.
> The difference is that JS has no binding ... just functions that take an argument named `this` Associating a name with a value is precisely what binding is. Frankly, though, I don't understand this comment at all . Care to clarify for me?
In Python b = foo.bar b() correctly invokes the bar method of the foo object. In JavaScript, you have to write let b = foo.bar.bind(foo) because foo.bar gives you a function (not a method) that doesn't remember which object it came from.
I'm aware of what you have to write in JS, and I'd argue that that's the behavior that's to be expected. I'm actually more surprised by Python's behavior here. Lua works the same way JS does, as does Common Lisp.