Hi,

I'm hoping someone could help me understand the pros and cons of the way some of the code in the book is written.

Often you see code like this:

trait TaxCalculation {
  type S <: TaxCalculationTable
  val table: S
}

What is the benefit of using a polymorphic type like this rather than writing:

trait TaxCalculation {
  val table: TaxCalculationTable
}

Or even:

trait TaxCalculation[S <: TaxCalculationTable] {
  val table: S
}

Similarly for function signatures:

def f[A <: Foo](a: A)

Versus:

def f(a: Foo)

Thanks for any insights,

Ashlin.

+1 I have the same question

159028 wrote:Hi,

I'm hoping someone could help me understand the pros and cons of the way some of the code in the book is written.

Often you see code like this:

trait TaxCalculation {
  type S <: TaxCalculationTable
  val table: S
}

What is the benefit of using a polymorphic type like this rather than writing:

trait TaxCalculation {
  val table: TaxCalculationTable
}

Or even:

trait TaxCalculation[S <: TaxCalculationTable] {
  val table: S
}

Similarly for function signatures:

def f[A <: Foo](a: A)

Versus:

def f(a: Foo)

Thanks for any insights,

Ashlin.

for type parameter S in first case or Foo in second case, one can provide an extension of the trait with a specialized type parameterized by C that extends S (or Foo) in which the details of the implementations can make use of methods or properties of C not available in S nor Foo.

So body of a particular implementation f[C](a: C) can make use of any specialization in C that may not exist in Foo.

Note that I am not addressing the question about

trait TaxCalculation[S <: TaxCalculationTable]