W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: Deprecating Future's .then()

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 5 Jun 2013 11:37:37 +0100
Message-ID: <CADnb78gc2VAbxkvsy13YEFQWYnBvy2UTi3o5dYsHLZWGe1YNng@mail.gmail.com>
To: "Mark S. Miller" <erights@google.com>
Cc: Domenic Denicola <domenic@domenicdenicola.com>, Sam Tobin-Hochstadt <samth@ccs.neu.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, Sean Hogan <shogun70@westnet.com.au>, "www-dom@w3.org" <www-dom@w3.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Alex Russell <slightlyoff@google.com>, es-discuss <es-discuss@mozilla.org>
On Tue, Jun 4, 2013 at 4:32 PM, Mark S. Miller <erights@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
> Promise.of.

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
would help.

Received on Wednesday, 5 June 2013 10:38:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC