Juan Ignacio Dopazo (2013-08-26T16:25:42.000Z)
On Mon, Aug 26, 2013 at 12:54 PM, 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.
>
> (...)


> 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".
>
> I don't believe it's unthinkable to ask the community to update their
implementations to match the spec either way. I see two reasonable options:

- Instead of full compat-duck, add another method to the spec and duck
check both. It can be flatMap() or done() if there's interest in either
- Use some sort of brand check that is easy to implement and hard to match
by mistake

Juan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130826/a0e53237/attachment.html>
domenic at domenicdenicola.com (2013-08-29T19:30:25.342Z)
On Mon, Aug 26, 2013 at 12:54 PM, 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.
>
> (...)


> 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".

I don't believe it's unthinkable to ask the community to update their implementations to match the spec either way. I see two reasonable options:

- Instead of full compat-duck, add another method to the spec and duck
check both. It can be flatMap() or done() if there's interest in either
- Use some sort of brand check that is easy to implement and hard to match
by mistake