huntc/scala-concurrent-compat — pull request #2 by huntc (2013-06-24 00:44:12+00:00)
Title: Nonpreferred option

This DeferredResult design is a simple re-factoring of CompletableFuture where by CompletableFuture's non-completion methods are removed.

Specific concerns with this interface as per CompletableFuture:
* it is not consistent with the Java 8 stream API.
* method names such as thenApply and thenCompose are different to names used by the stream API such as map and flatMap.
* CompletableFuture has a thenApply functor method, a thenCompose monad method, methods for handling failures, and methods for completing the future successfully or with an exception.
* There are a number of useful helper methods that it provides, but all of these could be achieved using the methods already mentioned.
* Methods such as thenApply have three versions: one that gets invoked synchronously by the completing thread or the calling thread if already completed; and then two “async” versions where the callbacks are invoked in the default or in a supplied execution context.
* Since CompletableFuture is not an interface it can only have one implementation. Other APIs that provide futures (Scala, Netty, Guava) cannot be wrapped by this interface, meaning that it will not play well with the rest of the ecosystem, and is therefore not a good candidate for being returned or accepted by an API.
* CompletableFuture leaks its internals including methods such as getNumberOfDependents and obtrudeValue. This leakage makes CompletableFuture appear as a low level concurrency construct and not an API abstraction that can be shared between libraries.