- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 18 Apr 2013 10:03:46 -0700
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: Brandon Wallace <brandon.wallace@yahoo.com>, "www-dom@w3.org" <www-dom@w3.org>
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
Received on Thursday, 18 April 2013 17:04:33 UTC