On Fri, Apr 12, 2013 at 11:10 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Apr 11, 2013 at 4:57 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
>> The conventional name for these two methods would be Future.resolve and Future.reject. The implementation would be
>>
>> Future.resolve = (x) => new Future(({ resolve }) => resolve(x));
>>
>> Future.reject = (reason) => new Future(({ reject }) => reject(reason));
>>
>> This has the added benefit of using "resolve" semantics, i.e. assimilating thenables (including existing promises on the web, like jQuery promises).
>
> Now that I've actually learned the difference between accept() and
> resolve(), I'd prefer that all three of the resolution methods exist
> as statics on the Future interface. You don't always want resolve
> semantics.
And, having thought about it more and been working on a
closely-related EventStreams proposal, I actually now propose the
following names:
Future.of(any value) => Returns an accepted future with that value.
Future.from(any value) => If the value is future-like, resolves on it.
Otherwise, identical to Future.of
Future.reject(any reason) => Returns a rejected future with that reason.
Each are identical to:
function (value) {
return new Future(function(r) { r.[accept/resolve/reject](value); }
}
The naming suggestions are meant to (a) parallel the collection APIs,
particularly Array, which uses Array.of() as a "simple constructor"
(really, it's the monadic lifting function), and uses Array.from() as
the "conversion constructor". I think these are readable and easy to
understand, and while there are good arguments for simple copying the
resolver's method naming, I think it's even better to follow the
developing naming standard I lay out above.
~TJ