Practical
 Advanced Kotlin
 in Practice Sebastiano Poggi
 @seebrock3r

Topics of the workshop ● Properties: lateinit, delegates ● Type system: type erasure and reified types ● Enum vs sealed classes ● Functions: top level functions, mixing in some functional code ● DSLs ● Destructuring and numbered components ● Opinions™

Properties ● val vs var ○ val is like final in Java ○ Immutable reference ○ No guarantees on the value immutability ○ var are mutable variables ○ Mutable reference and value

Properties ● What you don’t have a value right away? ○ lateinit var myVar ○ E.g., Dagger, Context-dependent values, etc ○ Zero overhead, can change afterwards ○ Check if initialised with ::myVar.isInitialized ○ For primitive types use by notNull() instead

Properties ● What if a value is expensive to produce and only used in some cases? ○ val myVal by lazy { … } ● Caches value once calculated, then can’t change anymore ● Synchronised (thread-safe) by default ⚠ ○ Can be made faster with LazyThreadSafetyMode.NONE ○ Check your threading model!

Type system ● Inherits JVM limitations ○ Type erasure loses type parameters’ information at runtime ● Is stricter in some regards ○ Has explicit covariance/contravariance keywords: in and out ○ No need to care much about them... except when you do ○ Seb’s top tip: try until the compiler is happy

Type system ● Reified types ○ Only available for inline functions ○ Allows compiler to resolve type parameters ○ No need to pass in classes explicitly as arguments ○ No need to specify type parameters explicitly (in most cases)

Enum and sealed classes ● Enumerations are enum classes ○ They work the same as in Java ● Sealed classes ○ Best of both worlds ○ Known set of values at compile time ○ Can be objects or (data) classes or a mix of them ● Use sealed classes for “enums with data” ○ E.g., kotlin.Result

Functions ● Member functions are declared on a class you own ● Extension functions can be declared on any class ○ Even final/closed classes ○ Statically dispatched ○ fun MyClass.myFun() → static void myFun(MyClass receiver)

Functions ● Functions don’t need to be in a class ○ Called top-level functions ○ Translate to static methods on JVM ○ In a virtual class called like the package ○ Functions can take functions as parameters ○ Higher-order functions

DSLs ● Create domain-specific languages ● Extension functions for scoping ● Higher-order functions to compose behaviour ● E.g.:
 fun user(block: User.() -> Unit): User { … }
 val user = user { name = "Roborbio" }

Functional code ● Kotlin is OO but has FP facilities ● Top-level functions ● Function types & lambdas ● Higher-order functions ● Rich collection processing APIs ● Sequences ● Lazy streams ● Can only be “played” once

Functional code ● Pure functions ● Regular functions ● No “outside” dependencies ● No side effects ● If you need them, isolate and make them explicit ● Great for some use cases ● Data processing ● Pipelines

Collection/sequence APIs ● Same idioms as general FP ● Mapping, filtering, grouping, aggregating, reducing ● Collection type-specific APIs ● Lists: get by position, sublist, binary search, … ● Maps: key/value aware functionality ● Sets: intersect, union, subtract

Destructuring declarations ● Special functions: componentN() ● Access constructor properties in order ● Data classes have them by default ● Destructuring declarations ● Unpack classes’ components ● data class User(val name: String, val surname: String, val email: String)
 val (name, surname) = myUser

and now… segment I like to call opinions!

and now… opinions! In a segment I like to call EVERYBODY HAS OPINIONSTM BUT I AM THE SPEAKER SO YOU ALL
 HAVE TO LISTEN TO MY RANTS NOW

Everybody has Opinions! ● Extension functions ● They’re awesome! But… ● Hard to discover, “break” encapsulation ● Avoid abusing them, same as util classes ● Prefer smaller scopes ● …unless used as entry point to 3rd party API ● Consider top-level functions instead ● Factor in Java interop

Everybody has Opinions! ● Delegate properties ● They’re cool but don’t abuse them ● Can obscure meaning and behaviour ● Lazy ● Don’t make inexpensive stuff lazy ● Prefer lateinit for “initialised later” idiom

Everybody has Opinions! ● DSLs ● You don’t always need a DSL for that ● Avoid being too “smart” and side effects ● Operator overloading ● Don’t unless it’s extremely obvious what you’re doing ● Avoid at all costs if any risk of surprising users ● Must be obvious that it’s an overload

Ready Player one Sebastiano Poggi
 @seebrock3r http://bit.ly/advanced-kotlin-workshop