Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECMAScript bind operator proposal

github.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: ECMAScript bind operator proposal

#31

Post by yladiz »

xbdjdjfksmcf wrote: post #17

This proposal really deserves the "kill it with fire" label. Adding new operators to do things that are already possible will only serve to make the language more complicated and code written in JS more difficult to understand and maintain. JS's minimalism is its greatest strength.

Using that argument, you could say that every mathematical operation can boil down to addition and subtraction, because multiplication, exponentiation, and division are just flavors of those two operators. However, they're really convenient and I think that if an operator adds enough convenience it's worth the overhead of a new operator.

You can argue that the new bind operator isn't so convenient compared to the .bind syntax, but your argument is a bit weak.

Re: ECMAScript bind operator proposal

#32

Post by gsnedders »

kinkdr wrote: post #20

Does anyone know the history behind "this"? Is there any other language that uses "this" to denote "current context"?

There are plenty of languages which have an (implicit or explicit) argument called something like "this" or "self" where the semantics of a x.y() call are "look up y on the x object, call it with x as the this argument". C++ fundamentally works like that (the look-up is compile time in the case of non-virtual functions, but like JS at runtime for virtual functions), Python, Java, etc.

The oddity with JavaScript is two-fold: firstly, the fact that it passes the global object (in non-strict code) given an z() style call (v. x.y() above); secondly, the fact that you can call a function with an explicit this argument using Array.prototype.call or Array.prototype.array.

What feels far more odd than that, though, is what the DOM does. It often acts as if there's been a method call, whereas in reality it's just called with an explicit this argument from C++. If you view a method dispatch as being a message (à la Smalltalk, a large influence on JS) then obviously an event's target is invoked as a message to the event. I obviously can't comment if that's what Brendan was thinking, but it seems like an obvious analogue.

Re: ECMAScript bind operator proposal

#33

Post by _greim_ »

boubiyeah wrote: post #30

The "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

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.

Re: ECMAScript bind operator proposal

#34

Post by marcusarmstrong »

yladiz wrote: post #29

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.

I've found using properties (which auto-bind) to be an easier solution.

Re: ECMAScript bind operator proposal

#35

Post by Achshar »

rfw wrote: post #2

Neat! Extension methods and getting rid of "var that = this;" in one! It seems that it also extends to full expressions on the right-hand side of ::, so you can even do, for using Array operations over things that look like arrays but not quite: document.querySelectorAll('p')::([].map)(f) instead of: [].map.call(document.querySelectorAll('p'), f) (replace [].map with Array.prototype.map if it feels less gross)

Why do that in the callback way at all? Why not simple

    for(const el of document.querySelectorAll('p')) {}
Why have the overhead of a callback to begin with. It reads SO much better as well.

Re: ECMAScript bind operator proposal

#36

Post by WhitneyLand »

Thinking about new language features in terms of, what percentage of JS developers will understand it and what percentage will be confused by it, there's an argument for just leaving things be.

I would bet 3 years from now less than half of developers will be able to explain :: in an interview. Not that a much higher percentage could explain 'this' but what's done is done.

Re: ECMAScript bind operator proposal

#38

Post by spion »

_greim_ wrote: post #33
boubiyeah wrote: post #30

The "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

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.

Re: ECMAScript bind operator proposal

#39

Post by spion »

aikah wrote: post #18
JasonSage wrote: post #7

Earlier quoted context omitted.

I respectfully disagree. It all has to do with this line: "By providing syntactic sugar for these use cases we will enable a new class of "virtual method" library, which will have usability advantages over the standard adapter patterns in use today." Essentially, you write functions that provide a certain behavior without being coupled to a specific class, so you can have a 'map' method that is called the same way no…

> It all has to do with this line: "By providing syntactic sugar for these use cases we will enable a new class of "virtual method" library, which will have usability advantages over the standard adapter patterns in use today." There is nothing that this proposal does that cannot be done today. It brings nothing new to the table aside from operator noise. I hope the committee pushes against these exotic features, lik…

"explicit" is in the eye of the beholder. Passing a this argument to any function even if its not attached to the object seems more explicit to me.

Re: ECMAScript bind operator proposal

#40

Post by gliese1337 »

Achshar wrote: post #35
rfw wrote: post #2

Neat! Extension methods and getting rid of "var that = this;" in one! It seems that it also extends to full expressions on the right-hand side of ::, so you can even do, for using Array operations over things that look like arrays but not quite: document.querySelectorAll('p')::([].map)(f) instead of: [].map.call(document.querySelectorAll('p'), f) (replace [].map with Array.prototype.map if it feels less gross)

Why do that in the callback way at all? Why not simple for(const el of document.querySelectorAll('p')) {} Why have the overhead of a callback to begin with. It reads SO much better as well.

It has different semantics. Your code is equivalent to a `forEach` call, not `map`. Calling `map` returns a new array containing the results of the callback, while a for loop or a `forEach` don't.
Post reply on HN