W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: A Challenge Problem for Promise Designers

From: Dean Landolt <dean@deanlandolt.com>
Date: Fri, 26 Apr 2013 16:07:32 -0400
Message-ID: <CAPm8pjqEnPZ5UOBwoURmSENOKMi7v96G_kZwFHKKmsvKuLmTFA@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: David Bruant <bruant.d@gmail.com>, Rick Waldron <waldron.rick@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
On Fri, Apr 26, 2013 at 3:47 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: David Bruant [bruant.d@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/
Received on Friday, 26 April 2013 20:08:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:49 UTC