Timeline for What is State, Mutable State and Immutable State?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 12, 2016 at 15:09 | history | edited | Robert Harvey | CC BY-SA 3.0 | added 15 characters in body |
| Apr 21, 2015 at 13:12 | comment | added | Simon B | In many languages, immutability can be enforced by declaring member variables as "const" or "final". Such variables can only be initialised by the constructor. Don't assume that private variables are immutable - they can still be modified by the class' own member functions (methods). | |
| Apr 11, 2014 at 0:16 | comment | added | Robert Harvey | I think of state as the value of some property of some entity. "Shipped" is a state. So is "Tax Rate." The weight of something is a state. Whether you are currently awake or asleep is a state. The color of something is a state. Meaningful information about something, held in some kind of computer memory. | |
| Apr 11, 2014 at 0:14 | comment | added | Aviv Cohn | I see. But anyhow, in programming when somebody says 'state', he/she always refers to something's variable correct? | |
| Apr 10, 2014 at 22:38 | comment | added | Robert Harvey | Immutability can be simulated by simply never writing to an object's private members once they are populated with initial values. Immutability can be enforced using a number of methods: not providing a setter method, requiring the initial value to be set using a constructor parameter, writing in a functional style, using constants, etc. | |
| Apr 10, 2014 at 22:29 | comment | added | Aviv Cohn | Thanks for answering. So basically, in OOP, when someone says 'state', they usually mean "an object's member variables"? If so, then 'mutable state' is public variables, or more common in OOP, private variables that can be changed through setter methods - while 'immutable state' is simply private member variables? | |
| Apr 10, 2014 at 17:31 | comment | added | Doval | For the benefit of Prog, the fact that a value never changes is also important because it's much easier to reason about. It can be used in as many functions/methods as you want and you know they can't change it. With mutable state you have to track the history of how that object's been used to figure out what its value has now. That's needless mental overhead if making it immutable doesn't complicate the program. | |
| Apr 10, 2014 at 17:26 | history | answered | Robert Harvey | CC BY-SA 3.0 |