Free variables in TCA dependencies
11 Apr 2021 ⇐ Notes archive(This is an entry in my technical notebook. There will likely be typos, mistakes, or wider logical leaps — the intent here is to “let others look over my shoulder while I figure things out.”)
Updates:
4/17/21:
Friend of the blog, Danny Hertz, brought up a good point: “one thing I’m curious about is how they make sure those globals are mutated on same thread.” Brandon replied with “it’s the responsibility of whoever makes the client — every spot dependencies is referenced, we know it’s on the main queue and if it wasn’t that’d be our error.”
TCA completely rewired how I think about dependencies (and, well, how non-TCA code I wrote in the past worked with so much implicit state). A loose end in my understanding of the designing dependencies series has been those mutable free variables hanging out alongside for cancellation handling. e.g. dependencies here in the SpeechRecognition case study (or at the bottom of the abbreviated version, below).
Van (a regular study group pal) and I paused with the lifecycle of this variable — is it initialized on app. launch? Lazily loaded?
The Swift Programming Language book had our back with the answer in the Properties section of the Language Guide chapter:
Global constants and variables are always computed lazily, in a similar manner to
lazystored properties. Unlikelazystored properties, global constants and variables do not need to be marked with thelazymodifier.
Aha! So, dependencies is initialized as needed, even without a lazy tacked on. TIL!