Why go purposefully against the existing terminology of the JavaScript
ecosystem? Just say “deferred” where you have “promise” and “promise” where you
have “future” and you avoid needless confusion and conflict.
This isn’t Scala; we have existing terminology for exactly these concepts. Just
use it.
From: Kevin Smith
Sent: November 14, 2012 11:23
To: David Bruant
CC: Mark S. Miller, EcmaScript
Subject: Re: Promises
If the second argument is optional, it's possible to have both one-arg and
two-arg styles in the same API.
What do people think about this idea?
Maybe - minimalism served the class proposal quite well. It might be a good
strategy here, too.
Here's what I'm thinking:
// Creates a new promise
let promise = new Promise();
// Resolves the promise (ala Q)
promise.resolve(value);
// Rejects the promise (ala Q)
promise.reject(value);
// A handle to the eventual value of the promise
promise.future;
// The then method (ala Promises/A+)
promise.future.then(val => {
// Success handler
}, err => {
// Error handler
});
// Returns a future for the value
Promise.when(value);
// Returns a rejected future with the specified error
Promise.reject(error);
// Returns a future for every eventual value in the list
Promise.whenAll(list);
// Returns a future for the first resolved future in the list
Promise.whenAny(list);
Initial implementation here: https://github.com/jscloud/Promise
I think it's important to separate "Promise" from "Future". Back in the
CommonJS mailing list days, there was contention between Promises/A (thenables)
and Promises/B (basically Q). But they really are complementary: futures and
promises.
- Kevin
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
