In my attempt to port my Adobe InDesign flash panels to FlexJS, it became clear to me very quickly that Promises is critical for a normal flow of code.
I needed to convert a synchronous flow of code to an asynchronous one and Promises is a very important piece of that. For things like network, async file access and processes, Promises is a much better code flow than events. It would be even better if we supported await and async functions, but I think Promises is the first step towards that goal. There are a number of MIT licensed implementations of Promises and a port to ActionScript should be very easy.[1] I would also like to change/augment HTTPService/URLLoader to return Promises as well so we don’t need events or standard callbacks. My question is how exactly it should work. Should Promise be a top level object or org.apache.flex.utils.Promise? If we want it to work using the native browser implementation without wrappers, it seems like it should be a top-level object. Another question is how to handle polyfills. I.E. does not have any Promise support built in, so a polyfill is needed for I.E. That might be a reason to wrap Promise in a flex class and include the polyfill in the implementation. Another advantage of rolling our own Promises is that we can add some of the advanced features to Promises which are in some of the implementations. The standard browser ones have a pretty basic API.[5] Thoughts? Harbs [1]https://github.com/ForbesLindesay/promisejs.org [2]https://github.com/then/promise [3]https://github.com/kriskowal/q/ [4]https://github.com/petkaantonov/bluebird [5]https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise
