Promise API about reactor HOT 3 CLOSED

I put a bit of a Promise Manifesto in the wiki.

from reactor.

The promises implementation that I have most experience with is when.js from the Cujo guys. In addition to being a Promises/A+ implementation, it also provides methods for coordinating the outcomes of multiple events. I like the API a lot and, setting the restrictions of Java vs JavaScript aside, there would be a lot of value in having the two APIs be similar.

There's also the benefit that when's already had a lot of eyeballs on it. At the very least, I think we should involve Brian and John in the discussion and learn from their experience.

This may well already be the intention, but I'd like to see a Promise API that's independent of Reactor.

from reactor.

I agree with what you are saying and upon reading what Jon wrote in the wiki, I'd say we are all pretty much on the same initial page, seeing if Promises/A+ works well for us. It is coincidentally what I'm most familiar with as I read a little while ago the blogs by Brian Cavalier (which appear to be done now) but are available still in google's cache here and here. I very much liked the value propositions described in there - keeping code complexity low for async invocations and assuring proper error handling. However, we should also look elsewhere. Chris Richardson has spent some time in the space, he made the following comments in email....

My favorite implementation of Futures is what's now in Scala 2.10 (formerly akka futures). Rich, powerful API. I strongly prefer this API over anything else I've seen.
Javascript promises seem ok - I've written some code that uses them - but they've always struck me as weird (compared to JVM futures) and not something to be emulated elsewhere. e.g.
Terminology doesn't seem quite right. I prefer using the Future interface as the consumer API and Promise as the supplier API.
For some reason, I took me a while to wrap my head around the docs - https://github.com/cujojs/when/blob/master/docs/api.md#api
As mentioned above, I'd like Promise be the consumer-side interface rather than the Future++ class and reactor.Future to be the consumer-side API.
Java 8 looks like it will have a better futures implementation so some alignment with that might be desirable, although once again I suspect Scala wins.

and also

I've been digging into Netflix's RxJava. If you look at the blog post - http://techblog.netflix.com/2013/02/rxjava-netflix-api.html - they beginning by pointing out the deficiencies of Java Futures. Their solution is RxJava. I rewrote the bad Java examples and their RxJava video grid example using Scala Futures - https://gist.github.com/cer/5416475 and https://gist.github.com/cer/5397346 - Scala Futures appears to handle their use cases quite nicely although I think there are scenarios where RxJava wins. I plan to blog about this in the next week or two.

We should understand the issues there and also the relationship with future interaces. I'm not quite clear on the distinction between consumer vs. producer side mentioned above. I'm also a bit familiar with .NET's 4.0 Task Parallel Library (TPL) and in .NET 4.5 they added some async/await keywords in addition to async methods on several i/o framework classes that seem quite nice. As .NET/Scala are a bit closer to Java in terms of API feel, these look to be promising areas for comparison.

from reactor.