Seeking inmutability

I recently opened up this PR on Tuist that turns models that represent the projects into structs. For some reason, which I don’t remember, I had the not-so-brilliant idea of defining them as classes. While that has been working fine, they don’t really need to be classes and moreover, they’ll cause troubles as we start optimizing things by introducing parallelization.

Classes don’t prevent mutation, so as soon as we add threads to the mix, we might start seeing some race conditions of crashes derived from the mutation of instances from different threads.

Interestingly, as part of this work I found out that we were mutating an instance of Target to change its infoPlist attribute to point to an Info.plist generated by Tuist. After turning the models into structs, Xcode complained about that not being possible. What I ended up doing was changing the code implementation to rather create a copy of the target with that attribute mutated.

Next week we are meeting to sync up on the state of the project, and optimization is one of the topics. I can’t wait to see this area being explored further. Since the inception of the project this is an area that we have disregarded. Perhaps to avoid the introduction of premature optimization.

Two years later, and after some large projects started to use Tuist, we realized there’s a lot to improve so feel it’s now the right time to tackle that problem.