Discuss
  • [Idea] Bind operator as some sort of property acessor

[Idea] Bind operator as some sort of property acessor

# Augusto Moura (8 years ago)

Before I open any suggestion for my ideia in the [bind-operator](// github.com/tc39/proposal-bind-operator) proposal, I like to know you guys' opinion about, and if even it is in the scope of the current proposal.

There are moments when we want to export instances methods binded with their objects, like num.toFixed.bind (num), most of the time to be used as high order functions. With the current proposal the best we can get is num::num.toFixed, what seems a bit weird and counterintuitive.

For example, let's say that for an unknow reason we want to copy a array to another using the push method. There are a few ways:

const unary = fun => a => fun(a);

const arr = [];


// With arrow functions
[1, 2, 3, 4].map(n => arr.push(n));


// With binding
[1, 2, 3].map(unary(arr.push.bind(arr)));

And again, the best way of doing this with the current proposal is something like:

[1, 2, 3].map(unary(arr::arr.push));

My idea, similar to double colon operator in Java 8, is that the expression foo::bar translates to: access bar in foo, if it is a function, returns the function binded to foo.

So:

// The two expressions below produce the same function
foo::bar;
foo.bar.bind(foo);

// So in our example instead of using something like
[1, 2, 3].map(arr::arr.push);
// we can use
[1, 2, 3].map(arr::push);

And yeah, it just decreases one word. However imagine the symbol as acessor instead of a operator, leaves the things really less confusing in my opinion.

It can be useful for React applications too:

class Button extends React.Component {
  alertText() {
    alert(this.props.text);
  }

  render() {
    // Instead of `this::this.alertText`
    return <button onClick={this::alertText} />;
  }
}

Imo, my idea has a different motivation e use case than the current proposal and because of that, needs to be splitted with the original. We can discuss other symbols than the ::, but I personally think that it fits perfectly and make some neat code when composing high order functions.

# Logan Smyth (8 years ago)

Unless I'm misunderstanding what you are looking for, I believe the current proposal accounts for this as ::arr.push with no expression before the ::.

Logan

# Augusto Moura (8 years ago)

Yeah, you are right. The docs seems a bit confusing and I didn't notice it. Thanks for the attention

# Leo Balter (8 years ago)

The array map was a bad choice for the examples and got me distracted. Anyway, the example for the operator (arr::push) is something that I agree with you and I believe I suggested this at the proposal more than an year ago. If im not wrong, there's a thread like issue discussing this.

::arr.push does not feel natural and much more if I have a property chain: ::foo.bar.baz. It looks ambiguous.