Revisiting types estevez cover

Revisiting Types in Kotlin

Introduction (0:00)

My name is Francisco Paco Esteres, and this is a talk about types, and about the way that you use them in while developing in Kotlin.

Classic Object Oriented Programming / Data (0:41)

Classic object oriented programming tells you that classes encapsulate both data and behavior.

When representing data in Java, because classes have to adhere to certain standards, you have the possibility of having null fields, constructors, or empty constructor with all the values.

There’s also the issue with immutability. As we’re moving toward a more multi-threaded paradigm, if there are mutable models, and they are shared among threads, you have cases where it’s inconsistent.

Types (2:27)

A type is a finite set of encapsulated operations. It defines a representation of either a value or a behavior associated with values. This can be represented with classes, and some need language support. The most important part is that they can be checked at compile time.

Types Available in Kotlin (4:02)

Primitives

Get more development news like this

In Kotlin, there is type coercion, meaning everything is not implicit. You cannot add to the sum of an integer and a float, or divide an integer and a float in a way that you have an unexpected behavior.

There is no distinction between base types and wrapped types. Everything happens behind the scenes, and only a single type is needed.

Functions

Functions are runtime objects, and they have first class support in Kotlin. You can have a function class that is like a value or a variable that’s sent around an application. You can create instances of every function or every method using the operator ::.

Suppose there’s a User Manager class, and there’s a get in that class you want to use elsewhere. You set the parameter with :: to create an instance.

Collections and combinators (6:20)

Collections and combinators have any loose types, array, map, sets. These are an implementation on top of the original Java classes and are interoperable with Java.

There are two types of collections: mutable and immutable. In Java, when a method is called on an immutable collection, you’ll get an exception. Because of this, we have separate interfaces for mutable and immutable lists.

To illustrate this, create an immutable collection by using listOf, and if you use immutableCollection and call add, you’ll get an error that states add is not a valid operation.

Immutable collections have operations such as map or filter. You’re able to pass a function that transforms from one to the other, and as a result, the function will have a lambda.

Classes (12:12)

Data Classes

With data classes, you are able to pass any number of values into the constructor, any number of parameters, and those parameters become the fills inside the class.

Because of the type system in Kotlin, there’s a difference between nullable and none nullable types. Every type that has a question mark at the end is defined as nullable.

It’s possible to instantiate a class with select values. For example, if there’s a class that has name, age, and location as properties, a new instance that may only have the location and name. A constructive pattern can be built into the object directly for this.

Enums

For enums, each are assigned a value and a position, and you can also access each one of the elements through reflection.

Sealed classes (16:17)

Though sealed classes are not available in Java, it’s not a new concept. It is something that already existed in other languages. They have been described as union types, Archer break data types, or tack unions; the only variation is the implementation for them.

With sealed classes, you’re trying to define your execution in a context that is checked by your compilers, and separate data from general behavior.

Demonstration (19:09)

Next Up: Kotlin in Depth #9: Instrumentation Testing Robots

General link arrow white

About the content

This talk was delivered live in October 2016 at Mobilization. The video was transcribed by Realm and is published here with the permission of the conference organizers.

Francisco Estevez

Paco Estevez is an Android developer at Facebook by day, and an opensource contributor by night. He’s been an early adopter of new paradigms and techniques in Android, like reactive programming with RxJava or a functional approach to Kotlin.

4 design patterns for a RESTless mobile integration »

close