Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to use Scala's this typing, abstract types, etc. to implement a Self type?

I couldn't find the answer to this in any other question. Suppose that I have an abstract superclass Abstract0 with two subclasses, Concrete1 and Concrete1. I want to be able to define in Abstract0 something like

def setOption(...): Self = {...} 

where Self would be the concrete subtype. This would allow chaining calls to setOption like this:

val obj = new Concrete1.setOption(...).setOption(...) 

and still get Concrete1 as the inferred type of obj.

What I don't want is to define this:

abstract class Abstract0[T <: Abstract0[T]] 

because it makes it harder for clients to handle this type. I tried various possibilities including an abstract type:

abstract class Abstract0 {   type Self <: Abstract0 }  class Concrete1 extends Abstract0 {   type Self = Concrete1 } 

but then it is impossible to implement setOption, because this in Abstract0 does not have type Self. And using this: Self => also doesn't work in Abstract0.

What solutions are there to this issue?

like image 278
Jean-Philippe Pellet Avatar asked Nov 30 '10 11:11

Jean-Philippe Pellet


People also ask

What is a Self type?

A self-type is a way to narrow the type of this or another identifier that aliases this . The syntax looks like normal function syntax but means something entirely different. To use a self-type in a trait, write an identifier, the type of another trait to mix in, and a => (e.g. someIdentifier: SomeOtherTrait => ).

What does self => mean in Scala?

It lets you create dependencies among modules. For instance: class System extends Base with CompA with CompB with CompC. If CompA needs to use something from CompC , it can be defined as: trait CompA { self: CompC => ... } In this case: class System extends Base with CompA with CompB.

What is type in Scala?

Scala is a statically typed programming language. This means the compiler determines the type of a variable at compile time. Type declaration is a Scala feature that enables us to declare our own types.

How does Scala determine types when they are not specified?

Non-value types capture properties of identifiers that are not values. For example, a type constructor does not directly specify a type of values. However, when a type constructor is applied to the correct type arguments, it yields a first-order type, which may be a value type.


2 Answers

This is what this.type is for:

scala> abstract class Abstract0 {      |   def setOption(j: Int): this.type      | } defined class Abstract0  scala> class Concrete0 extends Abstract0 {      |   var i: Int = 0      |   def setOption(j: Int) = {i = j; this}      | } defined class Concrete0  scala> (new Concrete0).setOption(1).setOption(1) res72: Concrete0 = Concrete0@a50ea1 

As you can see setOption returns the actual type used, not Abstract0. If Concrete0 had setOtherOption then (new Concrete0).setOption(1).setOtherOption(...) would work

UPDATE: To answer JPP's followup question in the comment (how to return new instances: The general approach described in the question is the right one (using abstract types). However, the creation of the new instances needs to be explicit for each subclass.

One approach is:

abstract class Abstract0 {   type Self <: Abstract0    var i = 0    def copy(i: Int) : Self    def setOption(j: Int): Self = copy(j) }  class Concrete0(i: Int) extends Abstract0 {   type Self = Concrete0   def copy(i: Int) = new Concrete0(i) } 

Another one is to follow the builder pattern used in Scala's collection library. That is, setOption receives an implicit builder parameter. This has the advantages that building the new instance can be done with more methods than just 'copy' and that complex builds can be done. E.g. a setSpecialOption can specify that the return instance must be SpecialConcrete.

Here's an illustration of the solution:

trait Abstract0Builder[To] {     def setOption(j: Int)     def result: To }  trait CanBuildAbstract0[From, To] {   def apply(from: From): Abstract0Builder[To] }   abstract class Abstract0 {   type Self <: Abstract0    def self = this.asInstanceOf[Self]    def setOption[To <: Abstract0](j: Int)(implicit cbf: CanBuildAbstract0[Self, To]): To = {     val builder = cbf(self)     builder.setOption(j)     builder.result   }  }  class Concrete0(i: Int) extends Abstract0 {   type Self = Concrete0 }  object Concrete0 {     implicit def cbf = new CanBuildAbstract0[Concrete0, Concrete0] {         def apply(from: Concrete0) = new Abstract0Builder[Concrete0] {            var i = 0            def setOption(j: Int) = i = j            def result = new Concrete0(i)         }     } }  object Main {     def main(args: Array[String]) {     val c = new Concrete0(0).setOption(1)     println("c is " + c.getClass)     } } 

UPDATE 2: Replying to JPP's second comment. In case of several levels of nesting, use a type parameter instead of type member and make Abstract0 into a trait:

trait Abstract0[+Self <: Abstract0[_]] {   // ... }  class Concrete0 extends Abstract0[Concrete0] {   // .... }  class RefinedConcrete0 extends Concrete0 with Abstract0[RefinedConcrete0] {  // .... } 
like image 158
IttayD Avatar answered Sep 22 '22 23:09

IttayD


This is the exact use case of this.type. It would be like:

def setOption(...): this.type = {    // Do stuff ...   this } 
like image 41
pedrofurla Avatar answered Sep 18 '22 23:09

pedrofurla