Migrating Kotlin Context Receivers

Last week’s refactoring ( • Abolishing Kotlin Cont... ) to remove our IO context receiver was relatively easy because the receiver was never actually referenced, it was just a marker.
Our transaction context receiver may carry state though, so to remove its use we are going to have to convert from function contexts to function parameters. This is the widest-ranging refactor that we have yet covered, and is hampered by IntelliJ’s tooling not properly supporting context receivers, but as you will see we still never had more than five minutes where the code didn’t compile and pass all the tests. This is crucial, as it means that we can make changes like this on the main branch, integrating regularly so that we won’t need a complex and risky merge when the whole task is complete.
In this episode
00:00:47 Review transaction context receivers
00:02:25 A context receiver is, in essence, just another parameter
00:03:05 Context parameter variance always was broken
00:04:02 Chase through the change in variance
00:06:40 Convert a constructor to a companion invoke to fix generics
00:07:20 Generics taint lots of code
00:10:15 Swapping function calls with expand / contract
00:11:46 We need to do the same for all Items subtypes
00:13:57 Commit before making a hard-to-reverse changes
00:14:23
00:14:39 Migrate clients to the new function by inlining the old one
00:15:04 which doesn't work
00:15:16 Write a non-context inTransaction to simplify the fixes
00:18:57 Getting tedious now
00:19:38 Failing tests points us to another structural problem
00:20:46 Commit once we are running to bank the progress
00:21:04 Speedrun the save operation
00:23:11 Finally Items has lost its context receivers
00:23:45 Remove our last context receivers from Stock
00:27:06 Review and commit
There is a playlist of TDD Gilded Rose episodes - • Test Driven Gilded Ros...
The codebase is available on GitHub github.com/dmc...
I get lots of questions about the test progress bar. It was written by the inimitable @dmitrykandalov. To use it install his Liveplugin (plugins.jetbra...) and then this gist gist.github.co...
Thanks to Orion Williams for the music toolofgod.com/...
If you like this video, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook (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.

[@PairingWithDuncan]

Late this week as I was having so much fun at SoCraTes Belgium that I forgot it was Friday!

[@JentaroYusong]

12:37 Wunderbar ✨
Love your refactoring videos. I appreciate your very structured approach on refactoring.
I've used to get stuck trying to refactor to much at the same time. I've been watching your videos for a long time now and have read the book a while ago, both of which helped me in improving my own refactorings over the years. Thank you for that.
Even though we had some areas of code where context receivers deemed a great fit over the last years, we refrained from using them as they were still experimental. While the refactoring does not look to bad, I'm still glad we opted for that approach, as some of the contexts might've span almost the whole application, which in turn would've resulted in refactorings affecting a lot of places in the code.
Of course a flexible startup like Gilded Rose can take some of those risks associated with adopting experimental technologies. 😉
Have a great weekend.

[@PairingWithDuncan]

Thank you for your kind words.
As you say, contexts are solving multi-layer propagation, and so require intervention at each layer.
I’m thinking of reverting most of this refactor in order to redo it when context parameters are finally available (skipping a compiler version).