3 ms·

> Who is responsible for keeping the state internally consistent ? What does this even mean? > The real problem here is not the mutability of the state, it is

> Who is responsible for keeping the state internally consistent ? What does this even mean? > The real problem here is not the mutability of the state, it is the ownership of it. 1. Start with an initial state 2. Pass a copy of that initial state into a function, let it return a slightly modified version of that initial state 3. Pass that slightly modified version into another function, wash rinse repeat The only ownership that is happening that needs to be worried about is the parent function passing a copy of state to a child function for the duration of that call, right?

nijave 5y ago
I think the parent post is suggesting a lack of cohesion. E.g. the things changing state are sprinkled around in too many different places--it makes it hard to reason about The solution really depends on the design pattern so the message tends to be fairly vague. From an OOP perspective, maybe more state modifiers should be instance methods are at least belong in the same namespace
tcgv 5y ago
> What does this even mean? He's referring to the Single-responsibility principle [1] [1] https://en.wikipedia.org/wiki/Single-responsibility_principle https://en.wikipedia.org/wiki/Single-responsibility_principl...
saiojd 5y ago
I feel like, what is confusing you is that the parent is talking using broader/more general terms, rather than about specifics i.e. the state as an object which you can pass inside functions. His point, I believe, is that what causes problems/bugs is often when partially invalid state is shared, not so much specific implementation details like "are the modifications to the state visible because of mutation or because a copy of the state is passed around explicitly".
Aaargh20318 5y ago
> What does this even mean? It means that you need to concentrate the actual code that manipulates the state and perform all state changes through this code to ensure that the state is always correct. OO solves this through the concept of encapsulation, but that is just one way of doing it. If you have code all over the place that can manipulate the state, then it becomes extremely hard to ensure that the state remains valid. I'm not talking about the ownership of the particular instance, I'm talking about what code is allowed to, and responsible for, making alterations to state instances in general. If I ask you what code can make changes to state, you should be able to point to a small-ish part of your codebase and say: only these functions can make alterations. Each of those functions should guarantee that the state they return is a valid state, that is: they are responsible owners. All functions that operate on the state have the main responsibility to keep the state valid (e.g. no player character inside an object). Each specific function has additional responsibilities (e.g. move the character if possible). In the example, the move function can take an existing valid state, and turn it into an invalid state, the player can be moved inside an object. So you when you think about what that function's responsibility should be: it is to attempt to move the main character to a new, valid position. If you think of it like this, you quickly realise that the move and collision detection functions should be combined. > The only ownership that is happening that needs to be worried about is the parent function passing a copy of state to a child function for the duration of that call, right? If you're passing a copy of state from one function to the next, and every function can just modify it in whatever way it wants to, they you basically have globals but with more copying.

nijave 5y ago

I think the parent post is suggesting a lack of cohesion. E.g. the things changing state are sprinkled around in too many different places--it makes it hard to reason about The solution really depends on the design pattern so the message tends to be fairly vague. From an OOP perspective, maybe more state modifiers should be instance methods are at least belong in the same namespace

tcgv 5y ago

> What does this even mean? He's referring to the Single-responsibility principle [1] [1] https://en.wikipedia.org/wiki/Single-responsibility_principle https://en.wikipedia.org/wiki/Single-responsibility_principl...

saiojd 5y ago

I feel like, what is confusing you is that the parent is talking using broader/more general terms, rather than about specifics i.e. the state as an object which you can pass inside functions. His point, I believe, is that what causes problems/bugs is often when partially invalid state is shared, not so much specific implementation details like "are the modifications to the state visible because of mutation or because a copy of the state is passed around explicitly".

Aaargh20318 5y ago

> What does this even mean? It means that you need to concentrate the actual code that manipulates the state and perform all state changes through this code to ensure that the state is always correct. OO solves this through the concept of encapsulation, but that is just one way of doing it. If you have code all over the place that can manipulate the state, then it becomes extremely hard to ensure that the state remains valid. I'm not talking about the ownership of the particular instance, I'm talking about what code is allowed to, and responsible for, making alterations to state instances in general. If I ask you what code can make changes to state, you should be able to point to a small-ish part of your codebase and say: only these functions can make alterations. Each of those functions should guarantee that the state they return is a valid state, that is: they are responsible owners. All functions that operate on the state have the main responsibility to keep the state valid (e.g. no player character inside an object). Each specific function has additional responsibilities (e.g. move the character if possible). In the example, the move function can take an existing valid state, and turn it into an invalid state, the player can be moved inside an object. So you when you think about what that function's responsibility should be: it is to attempt to move the main character to a new, valid position. If you think of it like this, you quickly realise that the move and collision detection functions should be combined. > The only ownership that is happening that needs to be worried about is the parent function passing a copy of state to a child function for the duration of that call, right? If you're passing a copy of state from one function to the next, and every function can just modify it in whatever way it wants to, they you basically have globals but with more copying.