0

And, in the same vein, why do promise libraries typically not provide a resolve() and reject() method on the promise itself, bypassing the need for a deferred object?

EDIT

OK, I understand and accept the importance of throw safety.

Additionally... I have been using promises in an eventually-resolved callback scenario which seems to require the defer pattern. That is, I have a class which will eventually be loaded with data and which exposes a promise as way to "listening" for the "loaded" event. The client will need to gain access to that callback-promise before any asynchronous activity has even begun. In this case, I use defer to generate a resolvable promise. Does this sound legit? Any suggestions for a better approach?

Paul
  • 9,285
  • 6
  • 29
  • 37
  • I suppose it is because the promise constructor won, the libraries align with ES6. – elclanrs Aug 25 '15 at 21:13
  • 1
    Bluebird's [deprecated APIs](https://github.com/petkaantonov/bluebird/blob/master/deprecated_apis.md) docs says it is "it is much more awkward and error-prone than using new Promise" - but maybe there's a more detailed discussion somewhere. – doldt Aug 25 '15 at 21:15
  • @elclanrs - if the reason is "to align with es6", why not deprecate the entire library? – Amit Aug 25 '15 at 21:15
  • @Amit: Why not deprecate lodash, after all `forEach` has been around since ES5. The reason is because these libraries add more functionality and focus on performance. – elclanrs Aug 25 '15 at 21:16
  • @elclanrs - 1st, I'm not the one who suggested the reason is related to ES6, you did, so maybe you can suggest the same logical answer to your lodash question. 2nd, lodash functions, including forEach are much more versatile, for example iterating objects. 3rd, you don't need a whole new promise implementation in order to add functionality, you only need to enable that functionality on top of native promises, but I guess that's simply not the reason – Amit Aug 25 '15 at 21:23
  • @elclanrs: Do you know *why* the promise constructor won ES6? – Bergi Aug 25 '15 at 22:12
  • @Bergi: No idea, I wished the API was a bit different, but that's what we got now... – elclanrs Aug 25 '15 at 22:51
  • @elclanrs: Go look at the duplicate then (and earn Benjamin another upvote :-)) – Bergi Aug 25 '15 at 22:52
  • @elclanrs: Just curious, what did you wish to be different? – Bergi Aug 25 '15 at 22:52
  • @Bergi: perhaps the overloading of `.map` and `.flatMap` into `.then`, I would have kept them separate. I'm not convinced of the benefits... – elclanrs Aug 25 '15 at 23:14
  • @elclanrs: Oh, right, I'm totally with you there (though I [call them `map` and `chain`](https://github.com/fantasyland/fantasy-land)); I thought you'd wanted to change the promise construction pattern – Bergi Aug 25 '15 at 23:20

0 Answers0