Add standard convenience functions for creating Promises to resolve groups of Futures.

[EliteMasterEric]

Several convenience functions which mostly mimic promise handling functionality from JavaScript. Definitely standard enough to be part of the base library.

• Promises.all() resolves an array of Futures, completing when all of the Promises are fulfilled or any of the Promises are rejected.
• Promises.allSettled() resolves an array of Futures, completing when all of the Promises are fulfilled or rejected.
• Promises.any() resolves an array of Futures, completing when any of the Promises is fulfilled or all of the Promises are rejected.
• Promises.race() resolves an array of Futures, completing when any of the Promises is fulfilled or rejected.

Good example use cases include calling lime.utils.Assets.loadImage() for each of an Array of images; you now have multiple promises, and want to wait for all of them to resolve before continuing.

[nanjizal]

Not expert in this area, I wonder have you evaluated Franco's code in relation to this.
https://github.com/fponticelli/thx.promise
it maybe old in relation to some haxe features but generally he was advanced in his use of haxe back then, and he was certainly not limited to mirroring just one language.

[EliteMasterEric]

Not expert in this area, I wonder have you evaluated Franco's code in relation to this.
https://github.com/fponticelli/thx.promise

thx.promise is not compatible with the lime.app.Promise and lime.app.Future classes, which are built into Lime and utilized by Lime and OpenFL's asynchronous asset fetching functions, among other things.

[nanjizal]

but you read understood and learned from Franco, or did you just consider if the code was compatible - because that would be disappointing. There are creatives you learn from and I suspect Franco for haxe is one of them, and if you learnt nothing from his work then your commit is probably shallow? Please take another look at franco's stuff and evolve.

[m0rkeulv]

Not sure why thx.promise would be relevant here, as far as i can tell this is just a few utility methods making existing lime code more convenient to work with.

i do wonder if the PromiseResult would be simpler as an Enum tho, just my two cents.

 enum PromiseResult<T> {
  Pending;
  Fulfilled(value:T);
  Rejected(error:Dynamic);
}

[player-03]

Why not add the functions to Promise?

[player-03]

PromiseResult and PromiseState could be combined into a single enum, with options being Complete(value:T) and Error(error:Dynamic).

The Pending option isn't even used, so you'd just drop that.

[player-03]

Better yet, just reuse the futures:Array<Future<T>> array that was passed into the function. That way users can use the API they already know instead of learning a new one.

[EliteMasterEric]

I just went to make some refinements to this PR, and tried to implement your suggestion to add the static functions to the Promise class instead of making a new Promises class.

However, I discovered that since Promise is an @:generic class, it does not support static variables or functions. Thus, I will have to revert it back.

Using Future rather than individual results seems to work well though.