Dean Landolt wrote: > On Tue, Mar 29, 2011 at 2:54 PM, Scott Sauyet <[email protected]> wrote: >> Dean Landolt wrote: >> But I contend that it has much the same surface area of your >> simplification. It's a matter of the difference between > >> Promise: >> then(/*Function*/ fn): Promise, will fire on resolve >> fail(/*Function*/ fn): Promise, will fire on reject > >> and > >> Promise: >> // will fire fn1 on resolve, fn2 or reject >> then(/*Function*/ fn1, /*Function*/ fn2): Promise > >> Those are fairly similar APIs. The advantage of the latter is that >> it's closer to the Promises/A proposal. The advantage of the former, >> to my eyes, is that it's cleaner to use. > > There's more advantages to the latter than aligning with a spec, though it > is hugely beneficial that all the various implementations are aligning on > this one common, ducktypable definition of a promise. As I explain below, > you can the former on the latter, but not the other way around, among other > reasons.
I think, though that jQuery's implementation aligns with that spec, with only one minor exception, which was noted by the author of the Promises/A spec in a response to a post by the author of the jQuery implementation (<http://jaubourg.net/38261410>): | Actually, the biggest exception/incompatibility I see is that | Promises/A specifies a new promise should be returned when | then() is called (and you are returning |this|). I actually | totally agree that Promises/A should not specify the return | of a promise. It should not specify anything about the return | value. If this specification was removed, your return values | would be completely compatible. > [ ... ] Now there's > more to a "promise" than just a then function. So you've completely blown > away the value of *ducktypable* promises. So what if there's a function > without a failback? Does it qualify as a promise? Or just a failback and no > callback? It complicates matters, that's all. > > Moreover, you can layer your fail helper API onto the Promises/A then > signature (as jQuery has done). You can't go the other way. That's why I say > it's the most simplified. That same article discusses simple wrappers to implement either one on top of the other. Both are fairly simple, but it's definitely simpler to implement Promises/A in Promises/J (the term Aubourg used to describe the jQuery version). The main reason for this is pretty clear: Promises/J is more granular: it's much easier to move from a granular interface to a course one than to move move the other direction. >>> [ ... ] But ugh, jQuery really made a mess of when. > >> In what way? > > For starters, when shouldn't always return a promise. The whole point of > when is that it accepts possible promises -- things that may not actually be > promises. Always returning a promise with when is infectious and > unnecessary, and it ruins one the primary advantages of promises -- unifying > sync and async APIs. If you must do that you should use another construct > (Kris Zyp's implementations use the "whenPromise" method for instance). > Again, this is a case where we've had established precedent and a > *long*history of use -- so I'm a little annoyed that jQuery completely > eschewed that with their when function to provide something *worse*. Yes, that sounds like a serious mistake. But it sounds correctable. I'd like to see them deal with it. > I've been using promises regularly for a few years now. They're wonderful. I haven't, but I've developed very similar interfaces over the years. And they are very useful. I like the idea of a simple interface to make programs work with many different implementations. I look forward to it. -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
