domenic at domenicdenicola.com (2013-08-29T19:15:10.322Z)
Correction to meta-summary. We got to this state of happy agreement by
purposely postponing two issues:
a) We encapsulated the question of "what is a thenable?" into an abstract
isThenable(v) function which we have postponed defining.
b) We have postponed pinning down what happens if one attempts to subclass
Promise.
Since the immediate issue is, what do we need to agree on to unblock DOM, I
think we can continue to postpone #b for a while. However, we still need to
settle #a asap. There are two approaches:
compat-duck) Maintain compatibility with Promise/A+ and thus with libraries
compatible with Promises/A+ and the clients of those libraries, grit our
teeth (like we did for `__proto__`) and codify its duck typing of thenables,
to whit:
```js
function isThenable(o) {
return o !== null && o !== void 0 && typeof o.then === 'function';
}
````
narrow-duck) Adopt some new mechanism, like a funny property name or unique
symbol that must be made visible on all things that wish to be considered
thenables. The intent is not to avoid duck typing entirely, but to avoid
accidental collisions, especially with those who already have unrelated
"then" methods.
Aesthetically, I prefer narrow-duck, just like a prefer a language without
`__proto__`. But for the same reason I pushed for `__proto__`, I feel I must
push for compat-duck.
Correction to meta-summary. We got to this state of happy agreement by purposely postponing two issues: a) We encapsulated the question of "what is a thenable?" into an abstract isThenable(v) function which we have postponed defining. b) We have postponed pinning down what happens if one attempts to subclass Promise. Since the immediate issue is, what do we need to agree on to unblock DOM, I think we can continue to postpone #b for a while. However, we still need to settle #a asap. There are two approaches: compat-duck) Maintain compatibility with Promise/A+ and thus with libraries compatible with Promises/A+ and the clients of those libraries, grit our teeth (like we did for __proto__) and codify its duck typing of thenables, to whit: function isThenable(o) { return o !== null && o !== void 0 && typeof o.then === 'function'; } narrow-duck) Adopt some new mechanism, like a funny property name or unique symbol that must be made visible on all things that wish to be considered thenables. The intent is not to avoid duck typing entirely, but to avoid accidental collisions, especially with those who already have unrelated "then" methods. Aesthetically, I prefer narrow-duck, just like a prefer a language without __proto__. But for the same reason I pushed for __proto__, I feel I must push for compat-duck. On Wed, Aug 21, 2013 at 6:03 PM, Mark S. Miller <erights at google.com> wrote: > Meta summary: AFAICT, Tab and I are in 100% agreement on all issues either > of us has raised! > > An non-meta summary will take more time ;). > > > On Wed, Aug 21, 2013 at 6:00 PM, Brendan Eich <brendan at mozilla.com> wrote: > >> Mark S. Miller wrote: >> >>> >>> Cool. That means we get a decent naming precedent for the monad ops, >>> and consistency with Array.of (which also happens to be a monadic >>> lifter, if you limit yourself to calling it with only a single >>> argument). >>> >>> >>> I agree that this naming analogy is a good thing. I raise my approval >>> magnitude to +1 ;). >>> >> >> Bart: Are we there yet? >> Homer: Just a little further... >> Bart: Are we there yet? >> Homer: Just a little further... >> etc. >> >> Can someone summarize for those of us who accidentally skipped a bunch of >> unread messages here? It sounds good from the last post ;-). >> >> /be >> > > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130821/d4c2d6c8/attachment-0001.html>