On Mon, Aug 26, 2013 at 9:17 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Mon, Aug 26, 2013 at 8:54 AM, Mark S. Miller <erights at google.com>
> wrote:
> > Since today this code will still typically work, and will in the near
> future
> > successfully become lazier, we should expect a lot of such code to exist
> by
> > the time we roll out our new standard. This brings us back to our need to
> > chose between "compat-duck", where thenable is simply (typeof obj.then
> ===
> > 'function'), and "narrow-duck", where some additional marking is
> required.
> >
> > If we wish to go with narrow-duck, we need to agree on and promote that
> > additional marking asap, before more such code accumulates, or we need to
> > give up on narrow-duck. We are faced not just with the legacy of all the
> > existing promise libraries that would need to add this additional
> marking to
> > their promises. We are also faced with all the users of these promise
> > libraries who hand-roll their own thenables as above, to be assimilated
> by
> > these promise libraries.
> >
> > IMO, I expect it is already too late for narrow-duck, and that we will
> find
> > we are already stuck needing to standardize compat-duck, even though it
> will
> > misinterpret some other existing non-thenable uses of "then".
>
> Yes. I hate it, because it's a terrible stomping all over the object
> namespace, but I think we do have to accept that "promise-like" means
> "thenable".  ;_;
>
> Note, though, that .flatMap() won't recognize a thenable as a promise.
>  There's no "promise-like" where flatMap() is concerned, because
> flatMap() is the monadic operation, and should be shared by all
> monads, so you have to distinguish types nominally rather than
> structurally.  (Or by using a side-channel structural check, like a
> brand, which blends the boundaries between the two.)
>
> This means that returning a thenable from a flatMap() callback will
> cause a TypeError rejection of the output promise.


+1. Agreed on all counts.




>  What about .resolve()?
>

pseudocode:

        resolve(obj) => isPromise(obj) ? adopt(obj) : accept(obj)

The isPromise above is nominal. If obj is a non-promise thenable, as in the
example, it will be accepted, not adopted. The isThenable check happens
*only* on the input side of .then, and so forcing only happens at that
point as well.




>
> ~TJ
>



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

+1. Agreed on all counts.




>  What about .resolve()?

pseudocode:

        resolve(obj) => isPromise(obj) ? adopt(obj) : accept(obj)

The isPromise above is nominal. If obj is a non-promise thenable, as in the
example, it will be accepted, not adopted. The isThenable check happens
*only* on the input side of .then, and so forcing only happens at that
point as well.