On 12/20/2013 04:38 PM, Kevin Smith wrote:
>
>     I highly doubt that will be possible -- experience strongly
>     suggests that every odd feature _will_ be relied on in the wild by
>     that time. If we think thenable assimilation is a problem then we
>     have to remove it now. I, for one, would welcome that. We could
>     still provide an _explicit_ thenable adaptor method in the Promise
>     API.
>
>
> Agreed 100%.  I'm skeptical that we've really done our homework
> analyzing the backward compatibility constraints for this design.
>
> Now that we have a proper cross-realm nominal Promise type (which we
> didn't have before), the right thing to do is to use nominal typing.
>  We should have started from that point and then figured out how
> current thenables can cope.
>
> Too late?
>
> Probably, but just for kicks, here's another solution:
>
> Provide a Promise subclass, BorgPromise (Star Trek reference) which
> does simple thenable coercion in its then function (no funky WeakMap).
>  All libraries which might interact with thenables switch to using
> BorgPromises.  At some point in the future usage of non-Promise
> thenables will approach insignificance, at which time BorgPromise
> libraries can freely switch to using regular Promises, and
> assimilation can fade into history.
>
What will the new DOM APIs return? Regular promises or Borg promises?

If they return regular promises, users will still need to know that they
cant `return $.getJSON()` from within
the callback of that DOM promise, because jQuery's 1.9 promise is just a
thenable.

If they return Borg promises, we're back to where we started: user
$.getJSON()'s source code, tries to
return parser that has a `.then` method for transformation chaining,
gets subtle errors, author of parser
library can't change method because it would break existing code, lint
tool can't warn author about .then
because it doesn't know if the author wants thenable assimilation or not.

Also, users will have to be aware at all times what kind of promise
they're interacting with.

Sorry, I don't think this is better than convertableToPromise (which is
assumed to be `true` when undefined)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131220/bb632286/attachment.html>

On 12/20/2013 04:38 PM, Kevin Smith wrote:

> Probably, but just for kicks, here's another solution:

What will the new DOM APIs return? Regular promises or Borg promises?

If they return regular promises, users will still need to know that they
cant `return $.getJSON()` from within
the callback of that DOM promise, because jQuery's 1.9 promise is just a
thenable.

If they return Borg promises, we're back to where we started: user
`$.getJSON()`'s source code, tries to
return parser that has a `.then` method for transformation chaining,
gets subtle errors, author of parser
library can't change method because it would break existing code, lint
tool can't warn author about .then
because it doesn't know if the author wants thenable assimilation or not.

Also, users will have to be aware at all times what kind of promise
they're interacting with.

Sorry, I don't think this is better than convertableToPromise (which is
assumed to be `true` when undefined)