Defining an IO Context in Kotlin
In the last episode ( • Master Functional Thinking - Actions,... ) we learned to distinguish actions from calculations, or, as functional programmers would have it, impure from pure functions. We saw that calculations are easier to test, refactor and reason with, but actions tend to proliferate, because code that calls an action becomes an action itself.
We would like to minimize the proportion of actions, so we used annotations to mark them to warn us when they appear. The problem with annotations is that the compiler doesn't really understand them, so it can't tell if we have missed an annotation. We tried here ( • (-: Bonus Episode :-) Auditing Action... ) but couldn't find any way to make it work.
The compiler does (mostly) understand the new context receivers though, so in this episode we try using contexts to mark actions, starting with the most common reason for code being impure - IO.
Thanks to Jordan Stewart ( / damaged ) for collaborating on this, part 66 of an exploration of where a Test Driven Development implementation of the Gilded Rose stock control system might take us in Kotlin. You can see the whole series as a playlist
• All Gilded Rose Episodes
and the code on GitHub
https://github.com/dmcg/gilded-rose-tdd
If you like this, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook
(http://java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style.
I have some free time between producing videos and working for team Gilded Rose. If you like these videos I'd like to work with you - please get in touch - [email protected]