Skip to content

Instantly share code, notes, and snippets.

View eaubin's full-sized avatar

eaubin

View GitHub Profile
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
import com.twitter.util.{Future => TwFuture}
import scala.concurrent.{Future => ScFuture, promise => ScPromise}
implicit def twFutureToScala[T](twFuture: TwFuture[T]): ScFuture[T] = {
val prom = ScPromise[T]
twFuture.onSuccess { res: T =>
prom.success(res)
}
twFuture.onFailure { t: Throwable =>
prom.failure(t)
}
@sadache
sadache / 1-post.md
Created September 5, 2012 22:14
Applicatives are too restrictive, breaking Applicatives and introducing Functional Builders

This post aims to document a practical design implementation we came up with when designing some APIs in Scala. Of course the concept is not Scala specific and applies to other functional languages.

If you don't want to go into the full introduction, this post talks about how Applicatives are too restrictive and breaking them into two independent components can be interesting for Contravariant and Invariant Functors. Jump to implementation attached.

We are taking JSON serialization/deserialization as a motivating example.

JsValue is the name of the type that represents the JSON AST. What we need is to be able to read a JsValue and produce an A:

trait Reads[A]{