5 ms·

With arrow functions released and class properties likely to be approved soon, this has minimal value and is probably not worth the cost of the extra complexity

• marcandre 10y ago
  Even with arrow functions, it's pretty frequent to have to write things like `...on('event', evt => this.onEvent(evt))` where `on('event', ::onEvent)` would be quite nice.
• JasonSage 10y ago
  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 matter what you're mapping over. Right now functional libraries like static-land, ramda, sanctuary, etc. are working hard to provide these functional primitives but it's still painful to write readable code that uses these. It's also worth pointing out that directly importing methods here is more efficient than importing entire classes if you're not using one of those emerging build systems that does very good tree-shaking. This is the closest JavaScript is going to get to letting you write your behavior as a suite of functions separately from specific classes—it's like a step removed from typeclasses.
  • sebdd 10y ago
    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 https://github.com/mindeavor/es-pipeline-operator
    • the_gipsy 10y ago
      Yes! Elm has it and it's very nice.
    • qwertyuiop924 10y ago
      No. Pipelining is handy, but not necessary. This binding is a well-known pain point in JS.
  • aikah 10y ago
    > 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, like the bind operator or the pipe operator. > Right now functional libraries like static-land, ramda, sanctuary, etc. are working hard to provide these functional primitives but it's still painful to write readable code that uses these. No it's not. explicit != painful . Do people really want to end up with a spec of the size of C++ spec ?
    • spion 10y ago
      "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.