AP2 makes laziness easy.
Mark S. Miller
erights at google.com
Mon Aug 26 09:22:28 PDT 2013
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>
> > Since today this code will still typically work, and will in the near
> > successfully become lazier, we should expect a lot of such code to exist
> > 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
> > 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
> > these promise libraries.
> > IMO, I expect it is already too late for narrow-duck, and that we will
> > we are already stuck needing to standardize compat-duck, even though it
> > 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()?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss