exactly so and by all means please feel free to use that, bluebird, rsvp, q, jakes es6 polyfill or any of the 5000+ libs for Promises [1]
though I suggest one limits the scope to the other 200+ libraries claiming A+ support! [2] ;P [1] https://www.npmjs.com/search?q=Promise [2] https://www.npmjs.com/search?q=Promise+A%2B On Tue, Jul 7, 2015 at 10:53 AM, Tyler Freeman <ty...@tappur.co> wrote: > I'd just like to mention that jQuery has promises built-in as the > $.Deferred object. It's not quite the same as the official Promises spec, > but can be used similarly in most cases. > > > On July 7, 2015 9:42:10 AM PDT, Brian LeRoux <b...@brian.io> wrote: >> >> We experimented with Promise polyfills and had nothing but trouble. I'd >> like to preface by saying: lets not get into a theory war. Some people like >> promises (fine) and some do not (also fine). My stance is that we should >> leave that choice up to our end users. >> >> Lets throw some facts out to colour things. >> >> 1. Promises are a spec that will land in browsers natively [1] >> 2. Promises as a concept have MANY polyfill implementations >> 3. The polyfill landscape is largely divergent and implement different >> flavors of the concept >> >> Since we implement a User Agent we *could* polyfill to spec. As a plugin. >> (Jake's is probably best [2]) I'd be in favor of this and making that THE >> plugin dep for companion plugins that require Promises. The problem with >> this is #3. If we have a window.Promise it could be clobbered by a user >> that is not super aware of how things are composed under the hood. If it >> *could* happen guess what: it will. Some frameworks even force the idea of >> Promises that may not be totally on spec. Older jQuery and Ember come to >> mind. >> >> The other way to solve this problem is patience. This is the path I am most >> in favor of. Lets wait out the native implementation to land in the various >> webviews and at such time we can start using those. >> >> Plugins really should wrap device and operating system API's (in my >> opinion) and we should leave library code for the user land to figure out. >> The Promise API *is a library* until such time as it has been implemented >> into the language runtimes natively (and not just speculatively >> standardized). Ok I guess faltered into the theory war part there. ;) >> >> [1] https://promisesaplus.com/ >> [2] https://github.com/jakearchibald/es6-promise >> >> >> >> >> On Mon, Jul 6, 2015 at 6:45 PM, Murat Sutunc <mura...@microsoft.com> wrote: >> >> Hey Paul, >>> Welcome to Cordova! I've looked at your changes on github and have some >>> early feedback. >>> >>> 1) As per spec you return a Promise on battery.js but to my knowledge we >>> don't have a fallback for ES6 Promises on platforms that don't support it >>> yet. I would like to know what other committers think about this problem. >>> 2) I think the old API and the new API can co-exist for a while before we >>> deprecate and remove the old one. I see that the new spec uses a different >>> method name so we should be fine here. >>> >>> Thanks, >>> Murat >>> >>> -----Original Message----- >>> From: Paul Contat [mailto:contat.p...@gmail.com] >>> Sent: Wednesday, July 1, 2015 12:38 AM >>> To: dev@cordova.apache.org >>> Subject: Introduction >>> >>> Hello everyone, >>> >>> My name is Paul Contat, and I'm an engineering student and currently doing >>> an internship at W3C focusing on aligning cordova API with W3C ones where >>> applicable, as part of the HTML5Apps EU project ( >>> >>> http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/ >>> ) >>> >>> For my internship, I’m planning to contribute to the cordova project, >>> starting by the BatteryStatus API ( >>> https://issues.apache.org/jira/browse/CB-6065) if it’s possible. >>> >>> I've just signed the ICLA, created an account on Apache JIRA so I’m ready >>> to start and submitted my first pull request: >>> https://github.com/apache/cordova-plugin-battery-status/pull/24 >>> >>> I’m looking forward to feedback on whether I’m on the right path for >>> updating the Battery plugin API; I’m in particular interested to understand >>> if and how the current API should be deprecated once we get to a stage >>> where the new API is deemed in a good enough shape. >>> >>> Best regards, >>> Paul >> >> >> > -- > Tyler Freeman > CTO, Tappur > http://tappur.co > > Sent from mobile >
