promise(function (resolver)) or promise(function (fulfill, reject, progress, cancellationToken, ...))

[ForbesLindesay]

If we go down the route of #3 then we need to decide what arguments get passed to the function. If people end up going different ways on this we'd have no interoperability, and this wouldn't be easy to change in a backwards compatible manner.

Do people prefer:

return new Promise(function (resolver) {
    resolver.fullfill('foo');
  });

(where resolver has properties for fulfill, reject, reportProgress, cancellationToken etc.)

or

return new Promise(function(fullfill, reject, progress, cancellationToken){
    fullfill('foo');
  });

(the order of these arguments is arbitrary now, but could never be changed once decided)

or

return new Promise(function (fullfill, reject, options) {
    fullfill('foo');
  });

(where options has properties for reportProgress, cancellationToken etc.)

[ForbesLindesay]

Personally I'm fairly happy with option 1 or option 3, but I think option 2 would be a bad idea (frustrating to implement in libraries that don't yet support everything and gets worse and worse if we change/add things).

I think I marginally prefer option 1 as I think it remains helpfully consistent with other APIs such as spawn, which might end up looking a bit like this:

spawn(function* (resolver) {
  var a = yield promiseA;
  resolver.reportProgress(0.5);
  var b = yield promiseB;
  resolver.reportProgress(1);
  return a + b;
});

[juandopazo]

I prefer Library.defer(function (fulfill, reject) {}) only if the number of parameters is never greater than 3.

If it needs to be greater than 3, some implementations would add more than 3 regardless of the standard (extending it) or we believe it may need more than 3 at some point in the future, then I prefer Library.defer(function (resolver) {}).

[ForbesLindesay]

There are currently these 4 things that we know we'll need to pass to the function based on the current specs in development. I believe Q might have some other wacky way to semi-resolve a promise @kriskowal ? I'm planning to make a library that supports hot/cold promises that start only when you call then.

So this number is going to increase, but we could just separate out fulfill and reject.

Another alternative:

return new Promise(function (resolver, fullfill, reject) {
    fullfill('foo');
    //or
    resolver.fulfill('foo');
});

(where resolver has properties for fulfill, reject, reportProgress, cancellationToken etc.)

That way if you just need fulfill, you could do something like:

return new Promise(function (_, fullfill) {
    fullfill('foo');
});

[domenic]

I am fairly strongly in favor of option 1, with resolver alone. Anything else seems needlessly messy.

[ForbesLindesay]

I'm weakly in favour of option 1, I also think we should only specify that first argument, so implementers can put extensions into the second argument.

[kriskowal]

I think we’re least likely to paint ourselves into a corner with option 1.

[briancavalier]

+1 for option 1

[briancavalier]

One potentially interesting observation is that with option 1, it's possible to have an identical resolver API for both a Promise(function(resolver){...}) approach and a let {resolver, promise} = defer() style approach (as per #2).

[novemberborn]

Just now catching up on the discussion here. +1 for option 1.

[kriskowal]

I happened on a chance to chat with Mark Miller today. He favors:

var promise = Q.promise(function (resolve) {
    resolve(value);
})

Where "resolve" may play both role of the "resolve()" function and "resolver" object in the sense that any additional methods may be properties of that function. Thus resolve.notify(progress).

MarkM also strongly favors the ability to pass "resolve" as a free function.

[domenic]

Back to the dual-role resolve function... :-/. That's always been confusing for me.

To clarify, I assume that resolve(notAPromise) fulfills promise with notAPromise, and resolve(otherPromise) fulfills or rejects promise in the same way as otherPromise.

Still, as long as it has .fulfill and .reject properties that do what you expect, it's not so bad. You could even see it as a useful way of "hiding" the function currently called deferred.resolve, and which we were considering calling resolver.become.

I also think it should be spelled Q.Promise or new Q.Promise.

[kriskowal]

MarkM is also adamant that fulfill(promise) is a terrible idea and that we should solve the pedagogical problems with resolve(value or promise) in some other yet-imagined way.

[kriskowal]

To be clear, MarkM’s complaint is that fulfill causes more pedagogical problems than it solves:

var rejection = reject(new Error("Can't do it"));
fulfill(rejection).then(function (x) {
    // x === rejection
})

[domenic]

Wow, that example seems perfectly straightforward to me. Rename x to fulfillmentValue and I think it makes total sense.

I guess the issue is whether you are dealing with maybe-promises, or whether you know at all times whether you have a promise or a non-promise value. My experience has always been the latter. And I think most people have the same experience. Otherwise we'd all be using Q.when(unknown, ...) instead of promise.then(...).

[novemberborn]

Where "resolve" may play both role of the "resolve()" function and "resolver" object in the sense that any additional methods may be properties of that function.

That'd work for me. Removes the temptation to make the resolver itself a promise, which Legendary does at the moment.

I guess the issue is whether you are dealing with maybe-promises, or whether you know at all times whether you have a promise or a non-promise value. My experience has always been the latter. And I think most people have the same experience.

Yup, it's only for specific APIs that won't necessarily return a promise I bring out when(). Default assumption is non-foreign promises.