I did not realize there was already a Promise implementation. Cool! It does need catch(), but otherwise it seems pretty complete.
> Please create an HTTPServiceWithPromises instead. Fine. > There is a Promise class in js.swc in the global package. If you > implement a SWF side for it you should be good to go. So you are suggesting to make it a top-level class. Right? Otherwise we’re not good to go. Another problem with the definition in js.swc is that then() returns an Object, while it should really return a Thenable. I don’t think Thenable is defined as an interface in JS. > IMO, polyfills should be beads you add to your Application beads if you > need them. Makes sense, although I’m not sure what the bead would look like. I think manually adding a polyfill for I.E. in the HTML is a reasonable work-around as well. > You can always roll out a more sophisticated Promise class in another > package. But why not have a more basic implementation that mirrors what > is in most browsers? Sure. That was my thought as well. My point was that if it would make sense to put Promise in an Apache package, it could make sense to add some additional functionality. On Nov 16, 2016, at 6:24 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 11/16/16, 1:52 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> 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. > > Please create an HTTPServiceWithPromises instead. Basic components should > remain basic. > >> >> My question is how exactly it should work. Should Promise be a top level >> object or org.apache.flex.utils.Promise? > > There is a Promise class in js.swc in the global package. If you > implement a SWF side for it you should be good to go. > >> 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. > > IMO, polyfills should be beads you add to your Application beads if you > need them. If you don't need support on IE (if you are mobile only, for > example) then why carry the polyfill around? > >> 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] > > You can always roll out a more sophisticated Promise class in another > package. But why not have a more basic implementation that mirrors what > is in most browsers? > > -Alex
