Type Safety in an Unsafe World
with Kotlin
Cody Engel, Staff Software Engineer @ PayPal
Slide 2
Slide 2 text
What is Type
Safety?
It is kind of confusing.
Photo: Matthew Hamilton via Unsplash
Slide 3
Slide 3 text
Robin Milner, A Theory of Type Polymorphism in Programming
“Well typed programs cannot go wrong.”
Slide 4
Slide 4 text
Going Wrong
Syntactically valid, but meaningless.
Type Safety by Michael Hicks - http://bit.ly/ple-type-safety
Slide 5
Slide 5 text
Well Typed
It may crash, but that is by design in Kotlin.
Type Safety by Michael Hicks - http://bit.ly/ple-type-safety
Slide 6
Slide 6 text
Well Typed, Continued
This is by design in Ruby and may also crash.
Type Safety by Michael Hicks - http://bit.ly/ple-type-safety
Slide 7
Slide 7 text
Cody Engel, Type Safety in an Unsafe World with Kotlin
“Some languages have stricter behavior
than others.”
Slide 8
Slide 8 text
What is Kotlin?
It is a strict, yet concise
programming language.
Photo: Marc Reichelt via Unsplash
Slide 9
Slide 9 text
Define Types
Name can be inferred to be a
String.
Slide 10
Slide 10 text
Define Mutability
A variable defined as “var”
can change.
Slide 11
Slide 11 text
Define Structures
Structured data is more
predictable.
Slide 12
Slide 12 text
Define Nullability
Nullability is opt-in.
Slide 13
Slide 13 text
Define
Concurrency
Coroutines make
concurrency simpler.
Slide 14
Slide 14 text
And The Unsafe
World?
That would be our APIs.
Photo: Jason Yoder via Unsplash
Slide 15
Slide 15 text
is_admin
As a boolean it works well.
Unfortunately, this wasn’t how it was actually modeled.
Slide 16
Slide 16 text
is_admin
Our permissions class was never safer!
However this is how we would model that information in Kotlin.
Slide 17
Slide 17 text
is_admin
Okay, technically this isn’t too bad.
Although, it is not the best way to model a boolean with JSON.
Slide 18
Slide 18 text
is_admin
Extension functions to the
rescue.
This could also be an extension property, but extension functions look better in Keynote
Slide 19
Slide 19 text
is_admin
Strings can also represent
numeric values which can
represent booleans.
I was pretty excited to make use of extension functions, so it was fine.
Slide 20
Slide 20 text
is_admin
Unfortunately String already
has a toBoolean function.
And that function is for converting “true” and “false” into a boolean
Slide 21
Slide 21 text
is_admin
I can’t recall if this was
actually possible with the
API.
However there is a good chance it could have been possible based on customer configurations.
Slide 22
Slide 22 text
is_admin
Fortunately, it isn’t too
difficult to add.
Nonetheless, it’d be great if this wasn’t required in the first place
Slide 23
Slide 23 text
is_admin
It was nullable though.
That’s okay though, nullability is actually pretty simple with Kotlin.
Slide 24
Slide 24 text
is_admin
Updating our extension
function to be on a nullable
Any works.
Since we type cast on non-null types, the else branch catches our null case.
Slide 25
Slide 25 text
Making The World
a Safer Place
How to design safer APIs.
Photo: Matthew Rumph via Unsplash
Slide 26
Slide 26 text
Stick to a strict API when rolling
your own specification.
Slide 27
Slide 27 text
Use an industry standard
specification, such as Open API.
Slide 28
Slide 28 text
Look at JSON alternatives such
as Protocol Buffers.
Slide 29
Slide 29 text
Let’s build some great and safe APIs.
• YouTube - bit.ly/cody-yt
• Twitter - bit.ly/cody-twitter
• Medium - bit.ly/cody-medium
Thanks!