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