What's keeping this from Stage 1?

[dead-claudia]

Edit: Keeping this list up to date.

TL;DR: See title.

This already has transpiler support, and has definitely fulfilled at least most of the requirements for Stage 1. These are the ones I can tell are very clearly, unambiguously met (pulled from the process document):

• Identified “champion” who will advance the addition
• Prose outlining the problem or need and the general shape of a solution
• Illustrative examples of usage
• High-level API
• Discussion of key algorithms, abstractions and semantics
• Identification of potential “cross-cutting” concerns and implementation challenges/complexity

I'm just wondering what's holding this back from Stage 1.

[zenparsing]

I'm the champion. : )

There are a couple of reasons that I haven't attempted to advance this proposal with TC39:

First, when I presented this proposal back in March, I received a fair amount of pushback on the following grounds:

• This proposal "abuses" this to support functional programming. ES6 made progress in "taming" the dynamic (and confusing) nature of this in JS, and the bind proposal would actually make things more confusing.
• Using the :: operator for "virtual methods" would confuse programmers about property access in general.
• The prefix :: is just kinda weird looking.

On balance, TC39 wasn't particularly supportive. We went ahead with getting it into Babel, though, in order to gather some feedback. That feedback has been really useful.

I believe that the next step is to decide whether we would be better off splitting the proposal into separate "method extraction" and "functional pipelining" proposals. I'm cautiously in favor of that.

The second big reason that I haven't advanced this proposal is that I don't think this is the right time for adding syntax to JS, with the big exception of async functions. I think we need to focus on just async functions for ES7/2016/whatever.

Too much syntax too quickly isn't a good thing, especially given the huge amount of syntax added with ES6.

[dead-claudia]

Okay. Understandable.

[shovon]

I'm curious about functional pipelining. How would that work out?

[dead-claudia]

Edit (Aug. 12, 2016): This is merely a strawman proposing a change to the proposal, not the actual proposal itself. Just to clarify.

---

@zenparsing I do like the idea of separating these two ideas.

First of all, method binding a la Java would look really nice. It could even open up the possibility of a property shorthand.

getBooks().then(JSON.parse).then(books => books.map(book => new Book(book)))

// Simplify constructor call
getBooks().then(JSON.parse).then(books => books.map(new::Book))

// Shorthand binding of book => book.length
books
  .then(books => books.filter(compose(::length, atLeast(5))))
  .then(books => books.map(new::Book))

Shorthand for book => book[prop]
books.then(books => books.map(::[prop]))

It would be incredibly convenient, and it is also very commonly used. It's also extremely optimizable.

As for a pipelining syntax, I was kinda thinking of something like this:

function *map(f) {
  for (const i of this) yield f(i)
}

function* concat() {
  for (const i of this) {
    if (i[Symbol.iterator]) yield* i
    else yield i
  }
}

function *flatten() {
  yield* this
    ->map(x => x->flatten())
    ->concat()
}

[dead-claudia]

And for the dynamic this problem, it's already come up in TypeScript land because JS already calls methods by delegation (prototypal vs classical), and there's no way to properly type Function.prototype.bind and friends without it.

class A {
  foo() { return "A!" }
  bar() { console.log(this.foo()) }
}

class B {
  foo() { return "B!" }
}

console.log(new B().bar()) // "B!"

[ssube]

@IMPinball I think the method being bound should be on the right of the operator, for consistency both internally and with other languages. Type::new or Type::static and instance::method provide a predictable way to reference a call of some sort, even though new is an operator (putting it before the type seems like you're inverting the application). All forms can desugar into simple arrow functions or even just function calls.

[dead-claudia]

@ssube Then how would you do something like Base.new.bind(Base)? It's not an unheard of name, and it could be the right name for some data types.

[ssube]

@IMPinball I think the property access should take care of that: instance::[new]. I'm not sure I've seen that in use, but explicitly marking it as the new property should work.

[dead-claudia]

@ssube I like that idea.

On Thu, Sep 17, 2015, 23:57 Sean Sube notifications@github.com wrote:

@IMPinball https://github.com/impinball I think the property access
should take care of that: instance::[new]. I'm not sure I've seen that in
use, but explicitly marking it as the new property should work.

—
Reply to this email directly or view it on GitHub
#24 (comment)
.

[zenparsing]

@shovon A pipelining operator (found in some languages like F# as |>) would address the "iterlib" use case described in this proposal. It would look like:

function fn(a, b) {
    console.log([a, b].join(", "));
}

"hello"->fn("world");
// > "hello, world"

Where the left hand side is used as the first arg in call to the function on the right hand side.

[dead-claudia]

Closing in favor of #26, as the initial questions have been answered.