Deprecating Future's .then()
Anne van Kesteren
annevk at annevk.nl
Wed Jun 5 03:37:37 PDT 2013
On Tue, Jun 4, 2013 at 4:32 PM, Mark S. Miller <erights at google.com> wrote:
> Given this direction, I think the one operation that serves as both
> Promise.resolve and Promise.fulfill should be the previously suggested
I think you still want Promise.resolve because it makes sense with
Promise.reject and the instance methods on PromiseResolver. Promise.of
would be a good alias to have.
> I am always worried though when people use the term "unwrapping" as I
> don't know what they mean. Does this mean flattening, assimilating, both, or
> something else? What I mean here is to so one level of flattening. As for
> whether .then should also do one level of assimilation if it sees a
> non-promise thenable, I could go either way, but prefer that it should not.
> The promise-cross-thenable case should be sufficiently rare that the cost of
> the extra bookkeeping should be negligible.
Sorry for the confusion. I thought you guys had already settled on
accepting what the DOM standard currently defines (no branding checks
of any kind, just use a callable then property, if any). If that's not
the case, writing out the desired behavior for then()/flatMap() here
More information about the es-discuss