3 ms·

I’m having a difficult time understanding the practical difference between watching an internal state object vs an external one. Surely if you can observe one y

I’m having a difficult time understanding the practical difference between watching an internal state object vs an external one. Surely if you can observe one you can just as easily observe the other, no? 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.

maleldil 2y ago
> 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.
- caspper69 2y ago
  I'm sorry I just think we're going in circles. 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.
  - Tainnor 2y ago
    > These would be just as traceable in your IDE/debugger. 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).
Tainnor 2y ago
> 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? 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) vs. fun createUser(username: String, password: String, tenant: Tenant) except imagine that the comment for that first function didn't exist (because nobody documents shit anymore these days). The second one is almost impossible to accidentally misuse, the first one can lead to all sorts of weird bugs.

maleldil 2y ago

> 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.

caspper69 2y ago
I'm sorry I just think we're going in circles. 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.
- Tainnor 2y ago
  > These would be just as traceable in your IDE/debugger. 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).

Tainnor 2y ago

> 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? 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) vs. fun createUser(username: String, password: String, tenant: Tenant) except imagine that the comment for that first function didn't exist (because nobody documents shit anymore these days). The second one is almost impossible to accidentally misuse, the first one can lead to all sorts of weird bugs.