My point wasn’t the functions. It was the promises. (I always execute functions which return promises because I find that a lot easier than constructing them inline…)
Constructing and resolving promises is a pattern I find very counterintuitive. > On Jan 21, 2019, at 7:07 PM, szogun1987 <[email protected]> wrote: > > Promise.all accepts promises, not functions that returns promises. > I can't feel anything painfull with promises, you can thread arrow function > as a shorthand class that implements interface version. > This class accepts contextual variables as constructor parameters, stores > them in fields, what makes them available once "execute" method is called. > Execute method accepts also value returned by predecessor, and value > returned by execute is passed to successor. > By the way many compilers work similarly behind the code. > > > > -- > Sent from: http://apache-royale-development.20373.n8.nabble.com/
