ShahOdin

import com.twitter.util.Future
import com.twitter.finagle.Service

//the method that we want to pass around
def foo(x:Int): Future[String] = Future.value(x.toString)

//the construct that depends on Services
def bar(service: Service[Int,String]) = service

ShahOdin

trait A
trait B
trait C
trait D
class E(a:A,b:B,c:C,d:D)


////////////////////////////////////////////////////////
//(I)function declaration.
////////////////////////////////////////////////////////

ShahOdin

object FSM {

  sealed trait State

  object State {
    sealed trait State1 extends State
    sealed trait State2 extends State
    sealed trait State3 extends State
  }

ShahOdin

sealed trait NaturalNumber
sealed trait _0 extends NaturalNumber
sealed trait _1 extends _0
sealed trait _2 extends _1
sealed trait _3 extends _2
sealed trait _4 extends _3
sealed trait _5 extends _4
sealed trait _6 extends _5
sealed trait _7 extends _6
sealed trait _8 extends _7

ShahOdin

sealed trait Bool

sealed trait True extends Bool
sealed trait False extends Bool
//////////////////////////////////////////////////

sealed trait Comparison {
  type Match[IfLT <: Up, IfEQ <: Up, IfGT <: Up, Up] <: Up

  type gt = Match[False, False, True, Bool]

ShahOdin

// Hidden dependency makes inheriting from implementation dangerous.
object BadObjectOrientation {

  trait Interface {

    protected def resourceA: Int

    protected def resourceB: String

    //only supposed to use A

ShahOdin

/*
 * In a service-based architecture, often multiple components have common dependencies. However, each is usually interested in
 * a fraction of the provided functionality in a dependency. As such, when testing a dependency, the components tend to mock the individual 
 * functionalities in place (in their spec file). This means that one usually ends up with a lot of mock duplication in spec files.
 * This is bad because these are hard to maintain. If a service's API were to change, the spec files mocking a functionality could
 * fail and one has to go through the tests on a one by one basis and update them individually. Moreover, this duplication means 
 * that a high level component, needs to potentially combine the provided mocks if one of its dependencies shared a dependency with itself. 
 
 * Below is a demonstration of a suggested way service components (http-services, actors, etc.) should mock their dependencies. 
 * They need to define a MockAPI which is a list of components they need, in order to pr