In what situations should abstract types be preferred over type parameters?
In Scala, an abstract class is constructed using the abstract keyword. It contains both abstract and non-abstract methods and cannot support multiple inheritances. A class can extend only one abstract class.
Language. Methods in Scala can be parameterized by type as well as by value. The syntax is similar to that of generic classes. Type parameters are enclosed in square brackets, while value parameters are enclosed in parentheses.
To use a generic class, put the type in the square brackets in place of A . The instance stack can only take Ints. However, if the type argument had subtypes, those could be passed in: Scala 2.
To add to my previous answer on Abstract type vs. parameters, you have also the JESSE EICHAR's recent blog post (2010, May 3rd) highlighting some key differences:
trait C1[A] {
def get : A
def doit(a:A):A
}
trait C2 {
type A
def get : A
def doit(a:A):A
}
In C2
case, the parameter is "buried" (as an internal abstract type).
(except, as retronym puts it, it is not actually buried, see below)
Whereas with generic type, the parameter is explicitly mentioned, helping other expressions to know what type they are supposed to used
So (C1: parameter):
//compiles
def p(c:C1[Int]) = c.doit(c.get)
It compiles, but you expose explicitly the 'A
' type you want to use.
And (C2: Abstract type):
// doesn't compile
def p2(c:C2) = c.doit(c.get)
<console>:6: error: illegal dependent method type
def p2(c:C2) = c.doit(c.get)
^
It doesn't compile because 'A
' is never mentioned in p2 definition, so doit
doesn't know at compile type what it is supposed to return.
When using abstract type and wanting to avoid any "type leaking" to the interface (i.e. wanting to expose what 'A
' actually is), you could specify a very generic type as a return for p2:
// compiles because the internals of C2 does not leak out
def p(c:C2):Unit = c.doit(c.get)
Or you could "fix" that type directly in the doit
function:def doit(a:A):Int
instead of def doit(a:A):A
, which means:def p2(c:C2) = c.doit(c.get)
will compile (even if p2 doesn't mention any return type)
Finally (retronym's comment) you can specify A
either explicitly by refining C2 abstract parameter:
scala> def p2(c:C2 { type A = Int }): Int = c.doit(c.get)
p2: (c: C2{type A = Int})Int
Or by adding a type parameter (and refining C2 abstract type with it!)
scala> def p2[X](c:C2 { type A = X }): X = c.doit(c.get)
p2: [X](c: C2{type A = X})X
So abstract are recommended:
C2
(but be wary of the definition of function using C2
)C2
, use abstract type (with bounded type abstraction)C2
types via traits, use abstract type (you won't have 'A
' to deal with when mixing C2
with your class: you mix only C2
)For the rest, where simple type instantiation is need, use Parameters.
(if you know that no extension will be needed, but you still have to handle several types: that is what Parameter types are for)
retronym adds:
The main differences are
C2
can only be invariant in A
,(as illustrating here:
trait T1 {
type t
val v: t
}
trait T2 extends T1 {
type t <: SomeType1
}
trait T3 extends T2 {
type t <: SomeType2 // where SomeType2 <: SomeType1
}
class C extends T3 {
type t = Concrete // where Concrete <: SomeType2
val v = new Concrete(...)
}
)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With