Single- versus multi-param factory

[domenic]

This is somewhat of a rehash of #7, but it's in the context of the latest strawman (#18).

Basically, the choices for parameters to factory are:

1. resolve + reject
2. resolver + resolver.reject
3. an object with resolve and reject properties

And the reason for choosing 2 or 3 over 1 is future extensibility.

[domenic]

I argue for 1, despite extensibility concerns.

• It matches current libraries and patterns, generally (WinJS's Promise constructor, then, and MarkM's Q.promise in the concurrency strawman).
• For progress extensibility, a third parameter would be added, paralleling the third parameter to then
• For cancellation, which is a special type of rejection, I would do reject.cancel or reject.withCancellation.

[briancavalier]

I like 1 as well. Both resolve and reject can act as extension points as needed.

[juandopazo]

In YUI we're going for 1. It's really easy to teach and understand because it hides the fact that there's another object around there.

I like reject.cancel!

[novemberborn]

Let's do 1.

[ForbesLindesay]

I like 1. Your suggestion for cancellation misses the point slightly, you're shouldn't be doing cancellation from the resolver/factory, you should be handling it and canceling the underlying operation.

function get(url) {
  return new Promise(function (resolve, reject, progress, onCancelled) {
    var xhr = getXHRObject();

    onCancelled(function () {
      xhr.abort();
    });

    xhr.onProgress = progress;

    //other xhr stuff
  });
}

Personally, the way I see it, we're going to add progress to then, we may as well add progress and cancellation to this, that's only 4 arguments. I can't see any reason we'd ever need a fith, so 4 seems fine.

[domenic]

Seems like we have consensus on 1, so, closing.

@ForbesLindesay: I don't think adding progress to then is a foregone conclusion, given how progress is kind of a hack. We'll see. And reject.cancel() is meant to reject the promise with a cancellation reason; I think the API for cancelling the underlying operation would look more like new Promise(resolverFunc, onCancelled) as per promises-aplus/cancellation-spec#7 or similar.

[ForbesLindesay]

I'd be fine with that too. The point I was making is that I don't think cancellation needs to be possible for anyone who's not got access to the promise, so they can just do promise.cancel(). Anyway, those are separate issues for discussion elsewhere.