Surely if you can mutate a state object and pass it, its state can get mutated equally deep within the codebase no different than a global, no?
What am I missing here? To me this just sounds like a discipline issue rather than a semantic one.
Using an explicit parameter obviates the need for discipline since you can mechanically trace where the value was set. In contrast, global values can lead to action at a distance via implicit value changes.
For example, if you have two separate functions in the same thread, one can implicitly change a value used by the other if it's thread-local, but you can't do that if the value is passed via a parameter.
A few posts up I clearly said use encapsulation and then mutate state via known methods. These would be just as traceable in your IDE/debugger.
Further, I have also repeatedly mentioned both module-level and thread-level "globals".
And I understand how concurrency works.
Take care.
A debugger can trace a single execution of your program at runtime. It can't statically verify properties of your program.
If you pass state to your functions explicitly instead of looking it up implicitly, even in dynamically typed languages there are linters that can tell you that you've forgot to set some state (and in statically typed languages, it wouldn't even compile).
Yes, that's one reason why shared mutable state should IMHO be kept to a minimum and immutable objects/structs should be preferred.
// this function will implicitly look up the tenant from some global context
fun createUser(username: String, password: String)
fun createUser(username: String, password: String, tenant: Tenant)
The second one is almost impossible to accidentally misuse, the first one can lead to all sorts of weird bugs.