Typing in Java,

Kotlin and Scala

 

Hanneli Tavante

Breandan Considine

Hi!

@breandan

@hannelita

Disclaimer

We will work on a single example

and rebuild it several times

It is not a language war!

We are going to discuss

some architecture concepts

Agenda

  • Representing Layouts in Java
  • Moving to Kotlin
  • Covariance and contravariance in Scala
  • Covariance and contravariance in Kotlin
  • ByteCode and type erasure
  • Why is this important?

Mobile

Vertical

Horizontal

Layout

How can we represent that in Java?

 

Layout

 

 

Vertical

 

 

Horizontal

 

class Layout {
    //superclass
}
class Vertical 
   extends Layout {

}
class Horizontal 
   extends Layout {

}

 

Vertical

 

 

Horizontal

 

 

Layout

 

Inheritance... meh

  • Tight coupling
  • Reusing base class for unrelated child

Can we come up with a better layout?

interface Layout {

}
class Vertical 
   implements Layout {

}
class Horizontal 
   implements Layout {

}

 

Vertical

 

 

Horizontal

 

 

Layout

 

Does this object have these skills?

Does this object understand this protocol ?

Name refactor

interface Orientation {

}
class Vertical implements
      Orientation {

}
class Horizontal implements
    Orientation {

}

It is time to add some methods

rotate()

rotate() applied to a Horizontal -> Vertical

rotate() applied to a Vertical -> Horizontal

Where should we place the method rotate() ?

interface Orientation {

}
class Vertical implements
      Orientation {

}
class Horizontal implements
    Orientation {

}
interface Orientation {

}
class Vertical implements
      Orientation {

    Horizontal rotate() {
        return 
         new Horizontal();
    }

}
class Horizontal implements
    Orientation {

    Vertical rotate() {
        return 
         new Vertical();
    }

}
interface Orientation {
   Orientation rotate();

}
class Vertical implements
      Orientation {

    Horizontal rotate() {
        return 
         new Horizontal();
    }

}
class Horizontal implements
    Orientation {

    Vertical rotate() {
        return 
         new Vertical();
    }

}

Can we make it better?

We also could use Generics

class Layout<T> {

}
class Layout<T> {

}
class Vertical {

}
class Horizontal {

}

 

Layout

 

 

Vertical

 

 

Horizontal

 

How do we restrict a Layout either Layout<Vertical> or Layout<Horizontal>

interface Orientation {

}
class Vertical implements
      Orientation {

}
class Horizontal implements
    Orientation {

}
class Layout<T extends Orientation> {

}

Can we have a generic Layout rotate() ? 

interface Orientation {
  Orientation rotate();
}
class Vertical implements
      Orientation {

    Horizontal rotate() {
        return new Vertical();
    }
}
class Horizontal implements
    Orientation {

    Vertical rotate() {
        return new Horizontal();
    }
}
class Layout<T extends Orientation> {
  public Layout(T t){
    this.t = t;
  }
  Orientation rotate(){
    t.rotate();
  }
}

We want to achieve:

Layout<Horizontal> layoutHorizontal = 
           new Layout<Horizontal>(new Horizontal());
layoutHorizontal.rotate();
Orientation result
=
Layout<Vertical> layoutvertical

We want:

(Layout<Vertical>)
layoutHorizontal.rotate();
=

Explicit casting

:(

Is there any way to avoid that?

Agenda

  • Representing Layouts in Java
  • Moving to Kotlin
  • Covariance and contravariance in Scala
  • Covariance and contravariance in Kotlin
  • ByteCode and type erasure
  • Why is this important?

In Kotlin:

interface Orientation {
    fun rotate(): Orientation
}
class Vertical : Orientation {
  override 
      fun rotate() = Horizontal()
}
class Horizontal : Orientation {
    override 
      fun rotate() = Vertical()
}
class Layout<out T : Orientation>(val t: T) {
}

In Kotlin:

class Layout<out T : Orientation>(val t: T) {
}

In Kotlin:

class Layout<out T : Orientation>(val t: T) {
}

@JvmName("rotateVertical")
fun Layout<Horizontal>.rotate(): Vertical = this.t.rotate()

@JvmName("rotateHorizontal")
fun Layout<Vertical>.rotate(): Horizontal = this.t.rotate()

Extension functions

In Kotlin:

val horizontal = Layout(Horizontal())
val vertical = Layout(Vertical())

// Type safe rotation!
var v: Layout<Vertical> = horizontal.rotate()
var h: Layout<Horizontal> = vertical.rotate()
h = horizontal.rotate().rotate()
v = vertical.rotate().rotate()

In Kotlin:

val horizontal = Layout(Horizontal())
val vertical = Layout(Vertical())

// Type safe rotation!
var v: Layout<Vertical> = horizontal.rotate()
var h: Layout<Horizontal> = vertical.rotate()
h = horizontal.rotate().rotate()
v = vertical.rotate().rotate()

/* Does not compile!
v = horizontal.rotate().rotate()
h = vertical.rotate().rotate()
*/

Agenda

  • Representing Layouts in Java
  • Moving to Kotlin
  • Covariance and contravariance in Scala
  • Covariance and contravariance in Kotlin
  • ByteCode and type erasure
  • Why is this important?

Redesign In Scala:

trait Orientation {}

Redesign In Scala:

trait Orientation {}

class Vertical extends Orientation {}

class Horizontal extends Orientation {}


Redesign In Scala:

trait Orientation {}

class Vertical extends Orientation {}

class Horizontal extends Orientation {}

abstract class Layout[+T <: Orientation] {
  def layout: T
}


Redesign In Scala:

trait Orientation {}

class Vertical extends Orientation {}

class Horizontal extends Orientation {}

abstract class Layout[T <: Orientation] {
  def layout: T
}

class VerticalLayout(v: Vertical) 
              extends Layout[Vertical] {
  override def layout = v
}

class HorizontalLayout(h: Horizontal) 
               extends Layout[Horizontal] {
  override def layout = h
}

 

Orientation

 

 

Vertical

 

 

Horizontal

 

 

Orientation

 

 

Vertical

 

 

Horizontal

 

Layout

 

Horizontal

 

Layout

 

Vertical

 

 

Orientation

 

LayoutVertical

LayoutHorizontal

In Scala

val layout: Layout[Orientation] = new 
                             HorizontalLayout(new Horizontal)

Compile error: "Expression doesn't conform to the expected type"

In Scala

val layout: Layout[Orientation] = new 
                             HorizontalLayout(new Horizontal)
abstract class Layout[T <: Orientation] {
  def layout: T
}

We need to tell the compiler that

Layout[Horizontal] is a subtype Layout[Orientation]

In Scala

val layout: Layout[Orientation] = new 
                             HorizontalLayout(new Horizontal)
abstract class Layout[+T <: Orientation] {
  def layout: T
}

We need to tell the compiler that

Layout[Horizontal] is a subtype Layout[Orientation]

(Covariance)

In Scala

abstract class Layout[+T <: Orientation] {
  def layout: T

  def rerender(layout: T)
}

Method to re-render the actual screen, keeping the layout.

In Scala

abstract class Layout[+T <: Orientation] {
  def layout: T

  def rerender(layout: T)
}

Compile error: "Covariant type occurs in contravariant position"

In Scala

abstract class Layout[+T <: Orientation] {
  def layout: T

  def rerender[T >: Orientation](layout: T)

}

Why does the injected argument needs to be contravariant?

In Scala

abstract class Layout[+T <: Orientation] {
  def layout: T

  def rerender(layout: T)

}
var layoutWrapper: Layout[Orientation] = 
            new HorizontalLayout(new Horizontal)
  layoutWrapper.rerender(new Vertical)

^That is not right.

That is why input arguments are contravariant.

Scala and Kotlin help you actively think about covariance and contravariance

Agenda

  • Representing Layouts in Java
  • Moving to Kotlin
  • Covariance and contravariance in Scala
  • Covariance and contravariance in Kotlin
  • ByteCode and type erasure
  • Why is this important?

Back to Kotlin

interface Orientation {
    fun rotate(): Orientation
}

object Vertical : Orientation {
    override fun rotate() = Horizontal
}

object Horizontal : Orientation {
    override fun rotate() = Vertical
}

Back to Kotlin

interface Orientation {
    fun rotate(): Orientation
}

object Vertical : Orientation {
    override fun rotate() = Horizontal
}

object Horizontal : Orientation {
    override fun rotate() = Vertical
}

class Layout<out T : Orientation>(val t: T) {
}

Back to Kotlin

open class Builder<out T : Layout<*>> {
    open fun build(): T = build()
}

Back to Kotlin

open class Builder<out T : Layout<*>> {
    open fun build(): T = build()
}

open class Renderer<in T> {
    open fun render(t: T) {
        println(t)
    }
}

Back to Kotlin

open class Builder<out T : Layout<*>> {
    open fun build(): T = build()
}

open class Renderer<in T> {
    open fun render(t: T) {
        println(t)
    }
}

fun covariance(horizontalBuilder: Builder<Layout<Horizontal>>,
               layoutBuilder: Builder<Layout<Orientation>>) {
    // Layout<Horizontal> is a subtype of Layout<Orientation> ✓
    val bldr: Builder<Layout<Orientation>> = horizontalBuilder
    
    // Layout<Orientation> is a supertype of Layout<Horizontal> ✗
    val hlbr: Builder<Layout<Horizontal>> = layoutBuilder //ERROR
}

Back to Kotlin

open class Builder<out T : Layout<*>> {
    open fun build(): T = build()
}

open class Renderer<in T> {
    open fun render(t: T) {
        println(t)
    }
}

fun contrav(layoutRenderer: Renderer<Layout<Orientation>>,
            horizontalRenderer: Renderer<Layout<Horizontal>>) {
    // Layout<Orientation> is a supertype of Layout<Horizontal> ✓
    val hlrd: Renderer<Layout<Horizontal>> = layoutRenderer
    
    // Layout<Horizontal> is a subtype of Layout<Orientation> ✗
    val lrdr: Renderer<Layout<Orientation>> = horizontalRenderer
}

Agenda

  • Representing Layouts in Java
  • Moving to Kotlin
  • Covariance and contravariance in Scala
  • Covariance and contravariance in Kotlin
  • ByteCode and type erasure
  • Why is this important?

JVM Languages

will loose the T parameter!

     class Layout {}

(type erasure)

Strategies

  • TypeTags and Shapeless libraries in Scala
  • Extension functions in Kotlin
  • Reified generics in Kotlin
  • Reflection
  • Manually store T in a field

Agenda

  • Representing Layouts in Java
  • Moving to Kotlin
  • Covariance and contravariance in Scala
  • Covariance and contravariance in Kotlin
  • ByteCode and type erasure
  • Why is this important?

To sum up

  • Think about different coding approaches
  • Different architectures
  • New concepts
  • Understand the goods and the bad parts of a language and when to use each of them

References

Thank you :)

Questions?

 

Typing in Java, Kotlin and Scala - Devoxx US 2017

By Hanneli Tavante (hannelita)

Typing in Java, Kotlin and Scala - Devoxx US 2017

  • 1,551
Loading comments...

More from Hanneli Tavante (hannelita)