Live data from Hacker News

ECMAScript bind operator proposal

github.com

21–30 of 50 posts

Re: ECMAScript bind operator proposal

#22
post #14

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…

Wouldn't a pipeline operator [1] be a more interesting solution for this instead of adding syntax that relies on the `this` keyword? [1] https://github.com/mindeavor/es-pipeline-operator

No. Pipelining is handy, but not necessary. This binding is a well-known pain point in JS.

Re: ECMAScript bind operator proposal

#23
post #15

I don't think Ecma-script needs new operators ,especially the kind of operators that will make it look like C++ , just to save a few key types. There needs to be a balance. A balance between all these tricks and readability.

This. – More important than any language features is the conceptual space of a given language. JS used to be (very) good at this, but is losing terrain lately.

Re: ECMAScript bind operator proposal

#24

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.

"Minimalism." Right.

Lua is minimal. Scheme is minimal. Forth is minimal. Hell, Brainfuck is minimal. JS isn't.

Re: ECMAScript bind operator proposal

#25
This proposal has been around for a while. I try keeping an open mind, since I've been wrong about many other syntactic features... But I just don't see this being that useful; none of the examples seem particularly compelling.

It's also worth noting that most (?) modern browsers already bind log to console. At least Chrome, Firefox, and Safari all support it. I don't have a Windows machine so I can't confirm if Edge supports it. Same goes for Node.

    [1, 2, 3].forEach(console.log)

Re: ECMAScript bind operator proposal

#26

This proposal has been around for a while. I try keeping an open mind, since I've been wrong about many other syntactic features... But I just don't see this being that useful; none of the examples seem particularly compelling. It's also worth noting that most (?) modern browsers already bind log to console. At least Chrome, Firefox, and Safari all support it. I don't have a Windows machine so I can't confirm if Edge…

> It's also worth noting that most (?) modern browsers already bind log to console.

And it should be in all modern browsers soon[1], as `window.console` is now a namespace: https://console.spec.whatwg.org/#console-namespace

[1]: https://developer.microsoft.com/en-us/microsoft-edge/platfor...

Re: ECMAScript bind operator proposal

#28
post #13
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)

This also works, by the way: [...document.querySelectorAll('p')].map(f) In the future, NodeList could extend Array which would make these workarounds redundant. Extending Array was made possible by ES6. Anyhow, I think having some kind of extension methods would be great.

> In the future, NodeList could extend Array which would make these workarounds redundant.

It would break the web, unfortunately. (We've experimented with NodeList.prototype.__proto__ being Array.prototype instead of Object.prototype and it breaks sites, and ES6's extends notion implies that.)

Re: ECMAScript bind operator proposal

#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.

Re: ECMAScript bind operator proposal

#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

Post reply on HN