Thenable

[cancerberoSgx]

I wonder If we could add support to this awesome library to accept more generic types than only Future and Promise as the library currently needs so functions can work with @async/@await syntax.

Currently when adapting this library to an existing project I must all my function/method implementations in order to return instances of this library's Future/Promise classes.

In JavaScript the solution for introducing async/await was to support any object that accepts a then method, not just a particular type instance. Basically the contract of JS async/await is that a statement like await foo will 1) if foo.then is a function then evaluate foo.then(function f(arg))and wait until f is called resolve using the value of arg. 2) if foo.then is not a function then resolve with just the value offoo.

That solved the problem of people start using async/await progressively on projects already using some pollyfill or library emulating promises, no matter the implementation or API, as long as those promises have a method then. (Thenables).

I'm currently on that situation where I would like to start using @async/@await syntax proposed by this library, but is unviable for me to refactor all my codebase (mostly based on a custom Promise implementation). And I don't think i will be able to integrate it progressively at all since in general methods calling each other will be a pain.

Any idea on this is most welcome, and concretely how hard/possible is to work on this problem . Thanks

[benmerckx]

One thing I've explored for other reasons, interopability with non haxe codebases, is overwriting the Promise abstract on the js target with one that uses a js promise as the underlying type instead of a Surprise.

But on the topic of async/await, this library is as far as I can tell not very actively used. Tink Promises were released after the initial release of this library and so far they've become expressive enough where I don't use tink_await, since sooner or later it can get you into hard to debug compile time (macro) problems. The codebase would need to become simpler (perhaps in a way you're describing) and have a clear way of dealing and propagating errors before I'd really recommend relying heavily on it. At some point I hope haxe provides language support.

You might also look into a more recent development which for now unfortunately requires you build the compiler plugin yourself: https://github.com/RealyUniqueName/Coro