Killing `Promise.fulfill`

Mark S. Miller erights at google.com
Tue Aug 20 07:08:30 PDT 2013


Hi Anne, Thanks for the reminder. My message of last night fell into that
same old trap (ignoring the storage cost) and that previous reversal of
mine is still mostly correct, However, the missing operation is not
.fulfill for the reasons Domenic correctly explains. It is .accept
(possibly named .of) because it observably differs from .resolve only to
.flatMap observers; whereas the distinction between "pending", "fulfilled"
and "rejected" is observable to .then observers.


On Tue, Aug 20, 2013 at 7:02 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Tue, Aug 20, 2013 at 2:48 AM, Mark S. Miller <erights at google.com>
> wrote:
> > I agree that an AP2 system, which is what we are discussing, should not
> have
> > a method named .fulfill for the reasons you state. A promise which, at
> the
> > AP2.flatMap level is "accepted" or "adopted" is, at the AP2.then level
> > "resolved". I suggest the method in question be called .resolve, that it
> > accept, not recursively unwrap/flatten/assimilate at all. The AP2.flatMap
> > programmer will understand .resolve as accepting. The AP2.then programmer
> > will understand .resolve as resolving.
>
> I remembered we previously reached this conclusion and then you ended
> up reversing yourself:
> http://lists.w3.org/Archives/Public/www-dom/2013AprJun/0213.html Did
> something change or am I misinterpreting something?
>
> (I'm in favor of removing fulfill() myself, for what it's worth.)
>
>
> --
> http://annevankesteren.nl/
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130820/dae9741b/attachment-0001.html>


More information about the es-discuss mailing list