A Challenge Problem for Promise Designers

Dean Landolt dean at deanlandolt.com
Fri Apr 26 13:07:32 PDT 2013


On Fri, Apr 26, 2013 at 3:47 PM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:

> From: David Bruant [bruant.d at gmail.com]
>
> > Which naturally leads to the question: why should platform promises be
> compatible with Promise/A+ and not jQuery "promises"? Because more
> libraries use Promise/A+? what about market share?
>
> What we're discussing is not *compatibility* but *ability to assimilate*.


The ability to assimilate stems directly from a need for library
compatibility. Seriously -- ask Kris Kowal who twisted his arm into having
Q accept thenables? :P


> Assimilating thenables requires no particular spec compliance or library
> compatibility. Promises/A+ (in the 1.1 version) gives a step-by-step
> procedure for doing so that is quite resilient in the face of edge cases,
> and so I'd recommend it for any assimilation semantics, but that's not
> terribly relevant to the question of whether there should be assimilation
> semantics *at all*.
>

What I'd really like to know is what is supposed to happen when a casper.js
[1] instance is returned by a promise? There is a lot of this code in the
wild. It's one thing when we're just talking about libraries which users
intentionally choose. But baking these assimilation semantics into the
language will create subtle interactions that are non-trivial to find and
debug. And for what? Compatibility with existing Promises/A+ libraries that
could easily make themselves compatible in other ways? That hardly seems
worth it.

[1] http://casperjs.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130426/bae8d9c9/attachment-0001.html>


More information about the es-discuss mailing list