A Challenge Problem for Promise Designers
bruant.d at gmail.com
Fri Apr 26 13:33:35 PDT 2013
Le 26/04/2013 21:47, Domenic Denicola a écrit :
> 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?
I realize I was playing the douchebag devil advocate here and I apologize for that.
The point I was trying to make is that there is no reason for the platform to follow a standard more than another. PromiseA+ has some user base and benefits, but jQuery has a much more massive user base and it would make sense for the platform to follow that. There are probably a bunch of other de facto standard here and there. Why should platform promises be more interoperable with promiseA+ and not any other (de facto) standard?
> What we're discussing is not *compatibility* but *ability to assimilate*.
I confused both as "having some level of interoperability".
> 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*.
As is, the algorithm is unacceptable as it unconditionally calls the
then method of a thenable potentially resulting in unintended
side-effects if the thenable wasn't intended to be a promise but a
I believe "does this object has a 'then' method?" is too weak of a
heuristic for a web platform convention. Trying an idea:
Step 2.3 of the Promise Resolution Procedure, instead of just "if then
is a function", what about "if then is a function *and* has a property
named '__IAmAPromiseA+Thenable__' which value is true, call it... "?
I don't think it would be possible (you'll tell me soon enough I
imagine), but that would be better.
Although this sounds crazier, it's a much better way to express the
intent that such then function is a thenable and I wouldn't be opposed
to this test even baked in the platform as it dramatically reduces the
risk of confusion.
More information about the es-discuss