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

>
>
> 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] =
future.then

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 }