W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

From: Kevin Smith <zenparsing@gmail.com>
Date: Fri, 26 Apr 2013 10:41:07 -0400
Message-ID: <CA+mDt2xUHuAwMQeGaOGkAJganrwktqFqqoLHQeLcimx7u2R12A@mail.gmail.com>
To: Juan Ignacio Dopazo <dopazo.juan@gmail.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
> Promise/A+ does not prohibit promises for promises. But in practice the
> problem is recognizing what is a promise.

I would say rather that we have two orthogonal, but
highly interfering issues:

1. Do we allow promises-(for-promises)+?
2. How do we recognize a promise type within the "resolve" operation?

I was going to wait for confirmation on Q, but I'll go ahead and say
somethin' foolish anyway : )

## Proposal ##

1. I don't see a problem with allowing nested promises, although I do see
it as an anti-pattern which ought to be avoided if at all possible.  I also
see promise-subclassing as an anti-pattern for the same reasons.

2.  We test for promise-ness using an ES6 symbol, if available, and
otherwise the string "then".

- Let `thenName` be "then"
- If the Symbol function is provided, then let `thenName` be Symbol()

Within the `resolve` operation, replace step 3 with:

- If value is a JavaScript Object, set `then` to the result of calling the
JavaScript [[Get]] internal method of value with property name `thenName`.

Add a Future.thenName property which returns `thenName`.

And finally, in the Future constructor, add something to this effect:

- If `thenName` is not the string "then", then set future[thenName] =

It's a little hacky but I'm sure it could be cleaned up by you W3C chaps.
 : )

Userland promise libraries would perform essentially the same operation in
their initialization routines:

    if (typeof Future === "function" && typeof Future.thenName === "symbol")
        this[Future.thenName] = this.then;

{ Kevin }
Received on Friday, 26 April 2013 14:41:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC